실행환경

• 1: intro
• 1.1: Overview
• 2: 공통기반 핵심
• 2.1: IoC Container
• 2.2: IoC Container Basics
• 2.3: Dependencies
• 2.4: Bean Scopes
• 2.5: Customizing the nature of a Bean
• 2.6: Bean Definition Profiles
• 2.7: Bean Definition Inheritance
• 2.8: Container Extension Points
• 2.9: The ApplicationContext
• 2.10: Annotation-based Configuration
• 2.11: Classpath Scanning for Managed Components
• 2.12: JSR 330 표준 어노테이션 사용하기
• 2.13: Java-based Configuration
• 2.14: Environment Abstraction
• 2.15: Inversion of Control
• 2.16: Generic
• 2.17: AOP 서비스
• 2.18: @AspectJ 어노테이션을 이용한 AOP 지원
• 2.19: XML 스키마 기반 AOP 지원
• 2.20: 실행환경 AOP 가이드라인
• 2.21: Resource 서비스
• 2.22: Spring Expression Language(SpEL)
• 3: 공통기반
• 3.1: Server Security Service
• 3.2: Architecture
• 3.3: Authentication
• 3.4: Authorization
• 3.5: 설정 간소화
• 3.6: Server Security 업그레이드
• 3.7: Session 방식 접근제어 권한설정
• 3.8: Scheduling 서비스
• 3.9: Logging
• 3.10: SLF4J
• 3.11: Log4j2
• 3.12: Log4j 2 환경설정 (코드 내에서 직접 설정 시)
• 3.13: Log4j 2 환경설정 (설정 파일 사용 시)
• 3.14: Id Generation 서비스
• 3.15: Property
• 3.16: Property Service
• 3.17: Property Source
• 3.18: Environment
• 3.19: Cache Service
• 3.20: EhCache
• 3.21: Cache Abstraction
• 3.22: Marshalling/Unmarshallig 서비스
• 3.23: XML Manipulation Service
• 3.24: Object Pooling Service
• 3.25:
• 3.26: Encryption/Decryption Service
• 3.27: Crypto 간소화 서비스
• 3.28: FTP Service
• 3.29: Mail 서비스
• 3.30: Compress/Decompress Service
• 3.31: 압축 파일의 종류
• 3.32: File Upload/Download 서비스
• 3.33: File Upload Service
• 3.34: Spring mvc Multipart Multi file upload 지원 문제
• 3.35: File Download Service
• 3.36: Tomcat 한글 설정하기
• 3.37: File Handling
• 3.38: Excel Service
• 3.39: String Util Service
• 4: 화면처리
• 4.1: MVC 패턴의 구조와 장점
• 4.2: Spring MVC Architecture
• 4.3: DispatcherServlet
• 4.4: HandlerMapping
• 4.5: Spring MVC Tag Configuration
• 4.6: Controller
• 4.7: Annotation 기반 Controller
• 4.8: Spring의 Validator 인터페이스와 유효성 검증
• 4.9: Bean Validation (JSR-303)
• 4.10: View
• 4.11: Map 객체를 통한 입력값 처리 방법
• 4.12: 스프링 WebFlux와 기존 스프링 웹 프레임워크 비교
• 4.13: Reactive Core
• 4.14: 스프링 WebFlux의 DispatcherHandler와 요청 처리 흐름
• 4.15: 스프링 WebFlux에서 어노테이션 기반 컨트롤러 활용 방법
• 4.16: 스프링 WebFlux 함수형 프로그래밍 모델(WebFlux.fn)
• 4.17: 스프링 WebFlux의 WebClient와 논블로킹 처리
• 4.18: Ajax 지원 서비스
• 4.19: Internationalization(국제화)
• 4.20: Security Service
• 4.21: Spring Framework + Jakarta Commons Validator
• 4.22: Commons Validator에 validation rule 추가하기
• 4.23: UI Adaptor Service
• 4.24: Asynchronous request processing
• 4.25: jQuery 가이드
• 4.26: WebSocket
• 4.27: STOMP over WebSocket 개요 및 메시지 처리 흐름
• 4.28: SockJS Fallback Options
• 4.29: UI - bootstrap
• 4.30: UX/UI Controller Component
• 4.31: HTML5 CSS3.0 JavaScript Module App Framework 기본 활용
• 5: 업무처리
• 5.1: Exception Handling 서비스
• 5.2: Spring Web Flow(SWF) 개요
• 5.3:
• 5.4: Spring Web Flow의 Hello World 예제
• 5.5:
• 5.6: Spring Web Flow 환경 설정
• 5.7: Spring Web Flow와 Spring MVC 연동
• 5.8: Spring Web Flow에서 보안 적용
• 5.9: Flow가 관리하는 영속성(Flow Managed Persistence)
• 5.10:
• 5.11: Flow 정의
• 5.12: Web Flow에서 Expression Language (EL) 사용
• 5.13: Spring Web Flow의 뷰(View) 보여주기
• 5.14: Action 실행
• 5.15: Flow 상속
• 6: 데이터처리
• 6.1: DataSource 서비스
• 6.2: Data Access 서비스
• 6.3: iBATIS Configuration
• 6.4: Spring-iBATIS Integration
• 6.5: iBATIS에서의 Data Type 매핑
• 6.6: iBATIS parameterMap
• 6.7: Inline Parameters
• 6.8: resultMap
• 6.9: iBATIS Dynamic SQL 사용
• 6.10: MyBatis
• 6.11: MyBatis 주요 변경점
• 6.12: MyBatis 시작하기
• 6.13: MyBatis Configuration XML File
• 6.14: Mapper XML Files
• 6.15: Mapper Dynamic SQL
• 6.16: MyBatis 적용 가이드
• 6.17: Spring Data
• 6.18: Spring Data Repository
• 6.19: Query Method
• 6.20:
• 6.21: MongoDB support
• 6.22: MongoDB Repositories
• 6.23: ORM 서비스
• 6.24: Entities
• 6.25: Entity Operation
• 6.26: Association Mapping
• 6.27: JPA Query Language
• 6.28: Native SQL
• 6.29: Concurrency
• 6.30: Cache Handling
• 6.31: Fetch Strategy
• 6.32: Spring과 JPA 통합
• 6.33: JPA Configuration
• 6.34: Transaction 서비스
• 6.35: 선언적 Transaction 관리
• 6.36: 프로그래밍 방식의 Transaction 관리
• 6.37: Spring Data - Reactive
• 6.38: R2DBC
• 6.39: MongoDB
• 6.40: Cassandra
• 6.41: Redis
• 7: 연계통합
• 7.1: Naming 서비스
• 7.2: Integration 서비스
• 7.3: Integration 서비스 Metadata
• 7.4: 연계 서비스 API
• 7.5: WebService
• 7.6: Restful
• 7.7: Cloud Data Stream
• 7.8: Swagger
• 8: 배치처리
• 8.1: 배치 실행환경 소개
• 8.2: SQLite
• 8.3: Logback logging
• 8.4: Job
• 8.5: Job Variable
• 8.6: Step
• 8.7: Step Variable
• 8.8: ItemReader
• 8.9: ItemWriter
• 8.10: Resource Variable
• 8.11: JobRepository
• 8.12: JobLauncher
• 8.13: Remote JobLauncher
• 8.14: JobRunner
• 8.15: JobRegistry
• 8.16: JobExplorer
• 8.17: JobOperator
• 8.18: Skip/Retry/Repeat
• 8.19: MultiDataProcessing
• 8.20: History Management
• 8.21: 동기/비동기 처리 예제
• 8.22: Listener (Pre/Post Processing)
• 8.23: 병행처리
• 8.24: Code Base Exception
• 8.25: 센터 컷(CenterCut)
• 8.26: 이벤트알림 템플릿 관리
• 8.27: Flow Control
• 9:

1 - intro

1.1 - Overview

표준프레임워크 실행환경 소개

개요

표준프레임워크 실행환경은 응용SW의 구성기반으로서, 응용SW 실행 시 필요한 기본 기능을 제공하는 환경을 의미한다.

즉, 전자정부 업무 구현을 목적으로 개발된 프로그램이 사용자가 의도하는 대로 정상적으로 실행될 수 있도록 지원하는 재사용 가능한 서버 실행 모듈, SW구조의 집합을 의미 한다.

목표

전자정부 표준프레임워크 실행환경은 ‘전자정부 서비스의 품질향상 및 정보화 투자 효율성 향상’을 위해 개발프레임워크 실행환경 표준을 정립하고, 개발프레임워크 표준 적용을 통한 응용 SW의 표준화 및 품질과 재사용성 향상을 목표로 한다.
또한, 모바일 웹의 사용성과 편의성 증대를 위하여 기존 실행환경 기반 개발이 가능한 모바일 웹 기반의 표준패턴 및 가이드 코드를 제공한다.

배경

현재 전자정부는 유사한 기능을 가지는 다양한 종류 및 버전의 프레임워크를 개별 시스템 단위로 적용/관리하고 있으며, 이에 따라 다양한 문제점들이 발생하고 있다.
전자정부에 적용된 개발 프레임워크는 Black Box 형태로 제공되어 사업자의 기술지원 없이는 응용 SW를 유지보수하기 어렵기 때문에 사업자에 대한 의존성이 발생한다.
복수개의 개발프레임워크가 적용된 사업의 경우, 개발프레임워크에 따라 개발표준 정의, 개발자 수급, 교육시행 등 별도의 유지보수 체계를 갖추는 중복 투자가 발생하며, 개발프레임워크의 체계적인 관리절차의 미비로 동일 개발프레임워크라 하더라도 버전 관리에 어려움이 있다.

따라서 전자정부 개발프레임워크의 표준화를 통하여

• 사업자 고유 개발프레임워크에 대한 기술 종속성을 배제하고,
• 프레임워크 표준화를 통해 응용 SW의 표준화와 품질 및 재사용성을 향상시키며,
• 개발 프레임워크의 유지 보수 단일화를 통한 투자 효율성을 높인다.
• 또한 모바일 표준 패턴 및 가이드 코드를 제시하여 프로그램 사용자의 편의성을 향상시킨다.

특징

표준프레임워크 실행환경은 전자정부 프레임워크에 대한 요구사항에 기반하고 기존 전자정부 프로젝트에 적용된 업체별 프레임워크를 비교 분석하여 38개 실행환경 프레임워크 서비스를 정의하였다.
표준프레임워크 실행환경은 서비스별 오픈 소스 소프트웨어 심사 과정을 거쳐 선정한 경량화된 표준프레임워크로서 사실상 업계 표준에 가까운 Spring 프레임워크를 기반으로 한다.
연계 솔루션에 독립된 전자정부 표준프레임워크 표준 연계 인터페이스를 정의하고 웹서비스 기반 구현체를 제공하며 모바일 웹의 경우 UX처리를 통합 웹서비스를 구현한다.

• 8개 서비스 그룹, 39개 서비스로 구성 - 표준프레임워크 실행환경은 화면처리, UX처리, 업무처리, 데이터처리, 연계통합, 배치처리, 모바일 서비스, 공통기반의 8개 서비스 그룹으로 구성되며, MVC, UX/UI Controller Component, IoC 컨테이너, AOP, Data Access, Integration 등의 핵심 서비스를 제공한다.
• 전자정부 프로젝트에 최적화된 오픈 소스 소프트웨어 선정 - 표준프레임워크 실행환경은 전자정부 프레임워크에 대한 요구사항에 기반하여 38개 서비스 별 오픈 소스 소프트웨어 심사 과정을 거쳐 최적의 오픈 소스 소프트웨어를 선정하였다.
• 경량화된 표준프레임워크로서 사실상 업계 표준에 가까운 Spring 프레임워크를 적용 - J2EE 표준을 준수하는 Spring 프레임워크를 채택함으로써 특정 업체의 WAS나 DBMS에 독립적인 환경을 제공한다.
• DI(Dependency Injection) 방식의 의존 관계 처리 - 표준프레임워크 실행환경은 Dependency Injection을 통해 객체나 컴포넌트 간의 의존성을 정의함으로써 변경 용이성과 재사용성을 향상한다.
• AOP(Aspect Oriented Programming) 지원 - 표준프레임워크 실행환경은 로깅, 트랜잭션, 예외처리와 같은 공통 관심 대상을 분리하여 정의함으로써, 개발자가 비즈니스 업무 개발에 집중할 수 있도록 한다.
• MVC Model2 아키텍처 구조 제공 및 다양한 UI 클라이언트 연계 지원 - 표준프레임워크 실행환경은 Spring MVC를 기반으로 하며, 다양한 UI 클라이언트 연계를 위한 인터페이스를 정의한다.
• 전자정부 표준프레임워크 표준 연계 인터페이스 정의 - 표준프레임워크 실행환경 표준 연계 인터페이스를 정의함으로써 연계 솔루션에 대한 의존성을 배제하고 독립적인 어플리케이션 개발이 가능하다.
• UX/UI Controller Component - 모바일 ‘웹’ 사용자 환경(UX/UI)에 대한 유연한 대응을 위해 Touch Optimized 된 필수 UI 컨트롤러 컴포넌트를 제공한다.

실행환경 서비스 구성

전자정부 표준프레임워크 실행환경은 8개 서비스 그룹으로 구성되며 38개 서비스를 제공한다. 실행환경 서비스 그룹 및 서비스는 아래 그림과 같다.

화면처리

화면처리 서비스그룹은 업무처리 서비스와 사용자간의 인터페이스를 담당하는 서비스로 사용자 화면 구성 및 사용자 입력 정보 검증 등의 기능을 지원한다.

• Ajax Support: Ajax는 대화식 웹 애플리케이션의 제작을 위해 HTML과 CSS, DOM, 자바 스크립트, XML, XSLT 등과 같은 조합을 이용하는 웹 개발 기법으로 Ajax 기능 지원을 위한 Custom Tag Library를 제공한다.
• Internationalization: Internationalization은 다양한 지역과 언어 환경을 지원할 수 있는 서비스로, 서버 설정 및 클라이언트 브라우저 환경에 따라 자동화된 다국어 기능을 제공한다.
• MVC: MVC 디자인 패턴을 적용하여 사용자 화면을 개발할 수 있도록 MVC 기반 구조를 제공한다.
• Validation: 웹 응용프로그램 작성 시 발생될 수 있는 웹 보안상의 취약점(XSS, SQL Injection 등)에 대응하기 위한 기능을 제공한다.
• UI Adaptor: 화면 레이어의 구현 방식에 따라 업무로직 레이어가 변경되는 것을 막기 위해서, 업무처리 Layer에서 사용할 데이터 타입을 정의하고, 화면 레이어에서 사용하는 in/out parameter를 해당 구현 방식에 맞게 변환해주는 기능 제공한다.

UX처리

UX 처리 서비스는 모바일 웹의 사용성과 편의성 증대를 위하여 사용자 경험 기능을 제공하고 시각,인터페이스,효과 경험이 가능하도록 지원한다.

• UX/UI Controller Component: 모바일 ‘웹’ 사용자 환경(UX/UI)에 대한 유연한 대응을 위해 Touch Optimized 된 필수 UI 컨트롤러 컴포넌트를 제공한다.
• HTML5 : 모바일 웹 페이지 구성 시 사용할 수 있는 마크업 언어로서 모바일 특화 태그 및 디바이스 API 제공한다.
• CSS3 : 모바일 기기 및 브라우저에 따라 적합한 컴포넌트가 보여지도록 한다.
• JavaScript Module App Framework : UX/UI controller component의 효율성을 보장하는 javascript 및 Json 구조를 제공한다.

업무처리

업무처리 서비스는 업무 프로그램의 업무 로직을 담당하는 서비스로 업무 흐름제어, 에러 처리 등의 기능을 제공한다.

• Process Control: 비지니스 로직과 업무 흐름의 분리를 지원하며, XML 등의 외부 설정으로 업무흐름 구성을 제공하고, 미리 정의된 프로세스를 실행하는 기능을 제공한다.
• Exception Handling: 응용 프로그래밍의 수행 과정에서 발생하는 예외사항(Exception)을 처리하기 위해 표준화된 방법을 제공한다.

데이터처리

데이터처리 서비스는 데이터베이스에 대한 연결 및 영속성 처리, 선언적인 트랜잭션 관리를 지원한다.

• Data Access: 다양한 데이터베이스 솔루션 및 데이터베이스 접근 기술에 대한 추상화된 접근 방식을 제공하여 업무 로직과 데이터베이스 솔루션 및 접근 기술 간의 종속성을 배제하기 위한 기능을 제공한다.
• Data Source: 다양한 방식의 데이터베이스 연결을 제공하고, 이에 대한 추상화 계층을 제공함으로써, 업무 로직과 데이터베이스 연결 방식 간의 종속성을 배제하기 위한 기능을 제공한다.
• ORM: 객체 모델과 관계형 데이터베이스 간의 매핑 기능인 ORM(Object-Relational Mapping) 기능을 제공함으로서, SQL이 아닌 객체를 이용한 업무 로직의 작성이 가능하도록 지원한다.
• Transaction: Database Transaction을 처리하기 위한 서비스로서, Transaction 처리에 대한 추상화된 방법을 제공하여 일관성 있는 프로그래밍 모델을 제공한다.

연계통합

연계통합 레이어는 타 시스템과의 연동기능을 지원한다.

• Naming Service: 원격에 있는 모듈 및 자원 등을 찾아주는 기능을 제공한다.
• Web Service: 연계 등을 위하여 업무 서비스를 웹서비스의 형태로 어플리케이션 외부에 노출시켜 타 시스템이나 어플리케이션에서 서비스를 이용할 수 있도록 하는 기능을 제공한다.
• Integration Service: 전자정부 시스템과의 연계를 위한 공통 인터페이스를 제공하여, 다양한 솔루션 연계 방식에 대한 표준 처리 방식을 제공한다.

배치처리

배치처리 서비스는 일괄처리 업무 구현에 필요한 기능을 제공한다.

• Batch Core: 배치기능 구현을 위한 Job 및 Step의 기본 설정 기능을 제공한다.
• Batch Execution: 배치기능 실행을 위한 JobLauncher, JobRunner 및 배치수행 정보를 저장하는 기능을 제공한다.
• Batch Support: 배치수행에 관한 다양한 부가기능 및 확장기능을 제공한다.

공통기반

공통기반 서비스는 실행환경 서비스 간에 공통적으로 사용되는 기능을 제공한다.

• AOP: 관점지향 프로그래밍(Aspect Oriented Programming: AOP) 사상을 구현하고 지원한다.
• Cache: 빈번히 사용되는 컨텐츠에 대해서 빠른 접근을 가능하게 하는 기능으로 잦은 접근을 통한 오버헤드나 시간을 단축시키는 역할을 한다.
• Compress/Decompress: 데이터를 압축 및 복원하는 기능을 제공한다. 데이터를 효율적으로 저장 및 전송하기 위해 원본 데이터를 압축하거나 압축된 데이터를 복원하여 원본 데이터를 구하는데 사용될 수 있다.
• Encryption/Decryption: 데이터에 대한 암호화 및 복호화 기능을 제공하며, 네트워크를 통한 데이터 송수신을 시 보안을 목적으로 사용될 수 있다.
• Excel: 엑셀 파일 포맷을 다룰 수 있는 자바 라이브러리를 제공한다.
• File Handling: File 생성 및 접근, 변경을 위해 File에 Access할 수 있는 기능을 제공한다.
• File Upload/Download: 화면처리 서비스 그룹에서 사용되며, 파일을 업로드 및 다운로드 하기 위한 기능을 제공한다.
• FTP: FTP(File Transfer Protocol) 프로토콜을 이용하여 데이터(파일)을 주고받기 위한 FTP 클라이언트 기능을 제공한다.
• ID Generation: UUID(Universal Unique Identifier) 표준에 따라 시스템에서 사용하는 ID(Identifier)를 생성하는 기능을 제공한다.
• IoC Container: 프레임워크의 기본 기능인 IoC(Inversion of Control) 컨테이너 기능을 제공한다.
• Logging: System.out.println 문을 사용한 오버헤드를 줄이고, 간편한 설정을 통해 로그를 저장하고 통제할 수 있는 기능을 제공한다.
• Mail: SMTP 표준을 준수하며 이메일을 송신할 수 있도록 이메일 클라이언트 기능을 제공한다.
• Marshalling/Unmarshalling: 객체를 특정 데이터 형식으로 변환하고, 반대로 특정 데이터 형식으로 작성된 데이터를 객체로 변환하는 기능을 제공한다.
• Object Pooling: Pool에 사용 가능한 객체가 있을 경우 객체를 할당 받거나, 없을 경우 Pool 크기에 따라 새로운 객체 생성 및 할당하는 기능을 제공한다.
• Property: 외부 파일이나 환경 정보를 구성하는 키와 값의 쌍을 내부적으로 저장하고 있으며, 어플리케이션이 특정 키에 대한 값에 접근할 수 있도록 기능을 제공한다.
• Resource: 국제화(Internationalization) 및 현지화(Localization)를 지원하기 위한 기능으로, 키값을 이용하여 국가 및 언어에 해당하는 메시지를 읽어오는 기능 제공한다.
• Scheduling: 어플리케이션 서버 내에서 주기적으로 발생하거나 반복적으로 발생하는 작업을 지원하는 기능으로서, 유닉스의 크론(Cron) 명령어와 유사한 기능을 제공한다.
• Server Security: 서버 함수 및 데이터 접근 시 보안 관리를 위해 사용자 인증 및 권한 관리 기능을 제공한다.
• String Util: 문자열 데이터를 다루기 위한 다양한 기능을 제공한다.
• XML Manipulation: XML을 생성하고, 읽고, 쓰기 위한 기능을 제공한다.

실행환경 오픈소스 소프트웨어 사용현황

실행환경의 서비스를 제공하기 위해 필요한 기반 오픈소스 소프트웨어를 도출하고, 오픈소스 소프트웨어 평가 및 테스트를 통하여 서비스별 오픈소스 소프트웨어를 선정하였다.
오픈소스 소프트웨어 평가는 산업 표준, 라이선스, 기능 요건, 성숙도 및 확장 시 지원, 개발 환경 등 다양한 항목에 대한 종합적인 평가를 수행하였다.
표준프레임워크 실행환경 서비스는 선정된 오픈소스 소프트웨어에 기반하여 재활용하거나 확장하여 구현되었으며, 일부 서비스는 선정 기준을 만족하는 오픈소스 소프트웨어가 선정되지 않았으며 자체 구현되었다.

2 - 공통기반 핵심

공통기반 핵심

Spring IoC Container는 객체(빈) 관리, 의존성 주입, Bean의 초기화와 소멸 등을 제공하며, 다양한 스코프와 프로파일 설정을 지원한다. 또한, Spring은 XML 스키마 기반 AOP, AspectJ 어노테이션, 그리고 리소스를 활용한 메시지 제공 서비스 등을 통해 개발자의 생산성을 높인다.

2.1 - IoC Container

IoC Container

개요

프레임워크의 기본적인 기능인 Inversion of Control(IoC) Container 기능을 제공하는 서비스이다.
객체의 생성 시, 객체가 참조하고 있는 타 객체에 대한 종속성을 소스 코드 내부에서 하드 코딩하는 것이 아닌, 소스 코드 외부에서 설정하게 함으로써, 유연성 및 확장성을 향상시킨다.

주요 개념

Inversion of Control(IoC)

IoC는 Inversion of Control의 약자이다. 우리나라 말로 직역해 보면 “역제어"라고 할 수 있다. 제어의 역전 현상이 무엇인지 살펴본다.
기존에 자바 기반으로 어플리케이션을 개발할 때 자바 객체를 생성하고 서로간의 의존 관계를 연결시키는 작업에 대한 제어권은 보통 개발되는 어플리케이션에 있었다.
그러나, Servlet, EJB 등을 사용하는 경우 Servlet Container, EJB Container에게 제어권이 넘어가서 객체의 생명주기(Life Cycle)를 Container들이 전담하게 된다.
이처럼 IoC에서 이야기하는 제어권의 역전이란 객체의 생성에서부터 생명주기의 관리까지 모든 객체에 대한 제어권이 바뀌었다는 것을 의미한다.

관련문서

• Martin Fowler가 저술한 Inversion of Control
• Inversion of Control 한글 번역

Dependency Injection

각 클래스 사이의 의존관계를 빈 설정(Bean Definition)정보를 바탕으로 컨테이너가 자동적으로 연결해주는 것을 말한다.
컨테이너가 의존관계를 자동적으로 연결시켜주기 때문에 개발자들이 컨테이너 API를 이용하여 의존관계에 관여할 필요가 없게 되므로 컨테이너 API에 종속되는 것을 줄일 수 있다.
개발자들은 단지 빈 설정파일(저장소 관리 파일)에서 의존관계가 필요하다는 정보를 추가하기만 하면 된다.

관련문서

• Martin Fowler가 저술한 Inversion of Control Containers and the Dependency Injection pattern
• Inversion of Control Containers and the Dependency Injection pattern 한글 번역 by 최범균(Blog 자바캔(Java Can Do It))

사용된 오픈 소스

• IoC Container는 https://spring.io/projects/spring-framework를 수정없이 사용한다.

설명

본 IoC Container는 Spring Framework의 기능을 수정없이 사용하는 것으로, 본 가이드 문서는 Spring Framework Documentation 을 번역 및 요약한 것이다.
Spring Framework IoC Container에 대한 상세한 설명이 필요한 경우, Spring Framework Documentation 원본 문서 및 Spring Framework API를 참조한다.

IoC Container of Spring Framework

org.springframework.beans과 org.springframework.context 패키지는 Spring Framework의 IoC Container의 기반을 제공한다.
BeanFactory 인터페이스는 객체를 관리하기 위한 보다 진보된 설정 메커니즘을 제공한다.
BeanFactory 인터페이스를 기반으로 작성된 ApplicationContext 인터페이스(BeanFactory 인터페이스의 sub-interface이다)는 BeanFactory가 제공하는 기능 외에 Spring AOP, 메시지 리소스 처리(국제화에서 사용됨), 이벤트 전파, 웹 어플리케이션을 위한 WebSpplicationContext 등 어플리케이션 레이어에 특화된 context 등의 기능을 제공한다.

요약하면, BeanFactory는 프레임워크와 기본적인 기능에 대한 설정 기능을 제공하는 반면에, ApplicationContext는 좀더 Enterprise 환경에 맞는 기능들을 추가로 제공한다.
ApplicationContext는 BeanFacatory의 완전한 superset이므로, BeanFactory의 기능 및 행동에 대한 설명은 ApplicationContext에도 모두 해당된다.

본 문서는 크게 두 부분으로 나뉘어지는데, 첫번째 부분은 BeanFactory와 ApplicationContext 모두에 적용되는 기본적인 원리를 설명하고, 두번째 부분은 ApplicationContext에만 적용되는 특징들을 설명한다.

• Basics
  IoC Container를 설명하기 위해 필요한 기본적인 개념 및 사용 방법을 설명한다.
• Dependencies
  IoC Container의 핵심 기능인 Dependency Injection의 사용 방식 및 설정 방법을 설명한다.
• Bean scope
  IoC Container에 의해 관리되는 Bean의 생성 방식 및 적용 범위를 설명한다.
• Customizing the nature of a bean
  Bean의 생명주기 관리, Bean이 속한 Container 참조 등 Bean의 성질을 변화시키는 방법을 설명한다.
• Bean definition inheritance
  Bean 정의 상속에 대해서 설명한다.
• IoC Container:Container extension points
  IoC Container의 기능을 확장하는 방법을 설명한다.
• IoC Container:The ApplicationContext
  ApplicationContext만이 제공하는 기능을 설명한다.
• IoC Container:Annotation-based configuration
  Java Annotation을 기반으로 Bean을 정의하는 방법을 설명한다.
• IoC Container:Classpath scanning for managed components
  Dependency Injection에 의해 삽입되는 base Bean에 대한 Java Annotation 기반 설정 방법을 설명한다.
• IoC Container:JSR 330 Standard Annotations
  JSR-330 표준 Annotation에 대해서 설명한다.
• IoC Container:Java-based configuration
  Java Annotation을 기반으로 Container를 구성하는 방법을 설명한다.
• Ioc Container:Environment Abstraction
  환경 설정을 추상화하는 방법을 설명한다.

참고자료

• The Spring Framework - Reference Documentation / 1. The IoC Container
• Inversion of Control
• Inversion of Control Containers and the Dependency Injection pattern
• |Inversion of Control Containers and the Dependency Injection pattern 한글 번역 by 최범균(Blog 자바캔(Java Can Do It))

2.2 - IoC Container Basics

Basics

개요

Spring Framework에서 객체가 생성자 인수, 팩토리 메서드에 대한 인수 또는 객체 인스턴스가 생성되거나 팩토리 메서드에서 반환된 후 객체 인스턴스에 설정된 속성을 통해서만 종속성(함께 작업하는 다른 객체)을 정의하는 프로세스를 제어의 역전(Inversion of Control, IoC)라고 한다. 의존성 주입(Dependency Injection, DI)은 모듈간의 의존성을 모듈의 외부 컨테이너 에서 주입시켜주는 기능으로 IoC의 한 종류이다.

설명

Spring Framework에서 Bean은 어플리케이션을 구성하고, IoC Container에 의해 관리되어지는 객체로 간단히 말해 IoC Container에 의해 객체화되고, 조립되고, 또는 관리되는 객체를 의미한다.
Bean들과 Bean들간의 종속성은 Container가 사용하는 설정 메타데이터에 의해 결정된다.

The Container

org.springframework.beans.factory.BeanFactory 인터페이스는 Spring IoC Container의 핵심 인터페이스로 Spring IoC Container는 객체를 생성하고, 객체간의 종속성을 이어주는 역할을 한다.

설정 정보(Configuration Metadata)

위 그림에서 보듯이, Spring IoC Container는 설정 정보(configuration metadata)를 필요로 한다. 이 설정 정보는 Spring IoC Container가 “객체를 생성하고, 객체간의 종속성을 이어줄 수 있도록” 필요한 정보를 제공한다.
설정 정보는 일반적으로 XML 형태로 작성된다. 설정 정보는 XML 형태가 아닌 Java Annotation을 이용하여 설정이 가능하다.
Annotation을 사용한 설정 방법은 Annotation-based configuration에서 설명하고 있다.

아래 예제는 XML 형태의 설정 정보의 기본적인 모습이다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans.xsd">
 
   <bean id="..." class="...">
       <!-- collaborators and configuration for this bean go here -->
   </bean>
 
   <bean id="..." class="...">
       <!-- collaborators and configuration for this bean go here -->
   </bean>
 
   <!-- more bean definitions go here -->
</beans>

<beans> tag는 Spring IoC Container의 설정 정보를 나타내는 tag이다. 그리고 각각의 <bean> tag는 Spring IoC Container가 생성하고, 관리할 객체의 정의를 나타낸다.
XML 설정 정보를 여러 개의 파일로 나뉘어 구성될 수 있다. 이 경우, 전체 설정 정보를 읽기 위해서 하나의 설정 파일에서 다른 파일을 import할 수 있다. Import 하는 방법으로 <import> tag를 사용한다.

<beans>
   <import resource="services.xml"/>
   <import resource="resources/messageSource.xml"/>
   <import resource="/resources/themeSource.xml"/>
 
   <bean id="bean1" class="..."/>
   <bean id="bean2" class="..."/>
</beans>

<import> tag의 resource attribute는 import할 XML 설정 파일의 위치를 나타낸다.

Container 객체화

다음은 Container를 객체화하는 한 예이다.

ApplicationContext context = new ClassPathXmlApplicationContext(new String[] {"services.xml", "daos.xml"});

// an Application is also a BeanFactory (via inheritance)
BeanFactory factory = context;

위 예제의 ClassPathXmlApplicationContext는 ApplicationContext의 한 종류이며, ApplicationContext 인터페이스는 BeanFactory 인터페이스를 상속하고 있다.

Container 사용 방법

Container를 객체화하면 getBean(String) 메소드를 사용하여 bean을 가져올 수 있다.

The beans

Spring IoC Container는 다수의 bean들을 관리한다. Container는 설정 정보를 사용하여 bean들은 생성한다. Container에서 사용하는 bean 정의는 아래 정보를 담고 있다.

• 클래스 이름(a package-qualified class name): bean의 실제 구현 클래스를 나타낸다.

• Bean 행동 정보(bean behavioral configuration elements): Container 안에서 bean이 어떤 식으로 행동하는지에 대한 정보를 나타낸다.(scope, lifecycle callbacks 등등)

• 다른 bean에 대한 참조(references to other beans): bean이 동작하기 위해 필요한 다른 bean들에 대한 참조 정보를 나타낸다. 이런 참조는 협력자(collaborators) 또는 종속성(dependencies)라고도 한다.

• 기타 객체에 설정할 정보들(other configuration settings): connection pool을 관리하는 bean에서 사용할 connection의 개수, 또는 pool의 최대 크기 등

위 개념적인 정보들은 실제 <bean> tag로 작성된다. <bean> tag를 구성하는 bean 정의는 아래 표와 같다.

Bean 이름(Naming beans)

모든 bean은 하나 이상의 id를 가져야 하며, 각각의 id는 Container안에서 단 하나만 존재해야 한다. 일반적으로 대부분의 bean은 하나의 id를 가지지만, 별명(alias)를 사용하여 둘 이상의 id를 가질 수도 있다.
Bean id에 대한 명명 규칙은 Java의 class field 명명 규칙과 같다. id는 소문자로 시작하고, 두번째 단어부터는 첫글자는 대문자로 작성한다. ‘accountManager’, ‘accountService’, ‘userDao’, ’loginController’ 등

Bean 별명(Aliasing beans)

<alias> tag를 사용하여 이미 정의된 bean에게 추가적인 이름을 부여할 수 있다.

<alias name="fromName" alias="toName"/>

name attribute는 대상이 되는 bean의 이름이고, alias attribute는 부여할 새로운 이름이다.

Bean 객체화(Instantiation beans)

모든 bean 정의는 객체화를 위해 실제 Java Class가 필요하다.
XML 설정에서는 ‘class’ attribute를 통해 Java Class를 설정한다. 대부분의 경우 Container는 bean를 객체화하기 위해서 Java의 ’new’ 연산자를 사용한다.
또는 특수한 경우, static 메소드를 사용할 수도 있다. 본 문서는 생성자를 이용한 객체화만을 설명한다.
생성자를 이용한 객체화는 가장 일반적인 방식으로, 다음과 같이 사용한다.

<bean id="exampleBean" class="example.ExampleBean"/>
 
<bean name="anotherExample" class="examples.ExampleBeanTwo"/>

참고자료

• Spring Framework - Reference Document / 1.1 Introduction to the Spring IoC Container and Beans

2.3 - Dependencies

Dependencies

개요

일반적인 엔터프라이즈 애플리케이션은 단일 객체(또는 Spring 용어로 빈)로만 이루어지지 않고 간단한 애플리케이션도 최종 사용자에게 일관된 사용자 경험을 제공하기 위해 여러 객체가 함께 작동한다. 이러한 객체들은 독립적으로 존재하며, Spring 프레임워크를 사용하여 각각의 빈으로 정의된다. 여기서는 독립적으로 정의된 여러 빈들이 협업하여 목표를 달성하는 방법에 대해 설명한다.

설명

종속성 삽입(Injecting dependencies)

종속성 삽입(Dependency Injection(DI))의 기본적인 원칙은 객체는 단지 생성자나 set 메소드를 통해서만 종속성(필요로 하는 객체)를 정의한다는 것이다.
그러면 Container는 Bean 객체를 생성할 때, Bean이 정의한 종속성을 추가하게 되는데 이는 Bean이 스스로 필요한 객체를 생성하거나 찾는 등의 제어를 가지는 것과는 반대의 개념으로 Inversion of Control(IoC)라고 부른다.
종속성 삽입에는 두 가지 방법이 있다. Constructor Injection과 Setter Injection이다.

Constructor Injection

생성자(Constructor) 기반의 DI는 다수의 arguments를 갖는 생성자를 호출하여 종속성을 주입한다. <constructor-arg> element를 사용한다.

package x.y;
 
public class Foo {
   public Foo(Bar bar, Baz baz) {
       // ...
   }
}

<beans>
   <bean name="foo" class="x.y.Foo">
       <constructor-arg>
           <bean class="x.y.Bar"/>
       </constructor-arg>
       <constructor-arg>
           <bean class="x.y.Baz"/>
       </constructor-arg>
   </bean>
</beans>

만약, <value>true</value>와 같이 type이 명확하지 않은 값을 사용하는 경우, Spring은 생성자의 어떤 argument에 해당하는지 결정할 수 없다.

package examples;

public class ExampleBean {
   // No. of years to the calculate the Ultimate Answer
   private int years;

   // The Answer to Life, the Universe, and Everything
   private String ultimateAnswer;

   public ExampleBean(int years, String ultimateAnswer) {
       this.years = years;
       this.ultimateAnswer = ultimateAnswer;
   }
}

Constructor Argument Type Matching

위와 같은 경우, ’type’ attribute를 통해서 각 argument의 타입을 지정할 수 있다.

<bean id="exampleBean" class="examples.ExampleBean">
   <constructor-arg type="int" value="7500000"/>
   <constructor-arg type="java.lang.String" value="42"/>
</bean>

Constructor Argument Index

위와 같은 경우 ‘index’ attribute를 통해서 각 argument의 위치를 지정할 수 있다.

<bean id="exampleBean" class="examples.ExampleBean">
   <constructor-arg index="0" value="7500000"/>
   <constructor-arg index="1" value="42"/>
</bean>

(* index는 0부터 시작한다.)

Setter Injection

Setter 기반의 DI는 argument가 없는 생성자를 통해 bean 객체가 생성된 후, setter 메소드를 호출하여 종속성을 주입한다. <property> element를 사용한다.

<bean id="exampleBean" class="examples.ExampleBean">
   <!-- setter injection using the nested <ref/> element -->
   <property name="beanOne"><ref bean="anotherExampleBean"/></property>
 
   <!-- setter injection using the neater 'ref' attribute -->
   <property name="beanTwo" ref="yetAnotherBean"/>
   <property name="integerProperty" value="1"/>
</bean>
 
<bean id="anotherExampleBean" class="examples.AnotherBean"/>
<bean id="yetAnotherBean" class="examples.YetAnotherBean"/>

public class ExampleBean {
   private AnotherBean beanOne;
   private YetAnotherBean beanTwo;
   private int i;
 
   public void setBeanOne(AnotherBean beanOne) {
       this.beanOne = beanOne;
   }
 
   public void setBeanTwo(YetAnotherBean beanTwo) {
       this.beanTwo = beanTwo;
   }
 
   public void setIntegerProperty(int i) {
       this.i = i;
   }    
}

종속성 상세 설정(Dependencies and configuration in detail)

본 장은 종속성 삽입에 사용되는 <constructor-arg>와 <property> element의 sub-element type을 설명한다.

명확한 값(Straight values(primitives, Strings, etc.))

사람이 인식 가능한 문자열 형태를 <value> tag를 사용하여 표현한다. String을 argument나 property의 type에 맞춰 변환해준다.

<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
   <!-- results in a setDriverClassName(String) call -->
   <property name="driverClassName">
       <value>com.mysql.jdbc.Driver</value>
   </property>
   <property name="url">
       <value>jdbc:mysql://localhost:3306/mydb</value>
   </property>
   <property name="username">
       <value>root</value>
   </property>
   <property name="password">
       <value>masterkaoli</value>
   </property>
</bean>

<value> element 대신 ‘value’ attribute를 사용할 수도 있다.

<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
   <!-- results in a setDriverClassName(String) call -->
   <property name="driverClassName" value="com.mysql.jdbc.Driver"/>
   <property name="url" value="jdbc:mysql://localhost:3306/mydb"/>
   <property name="username" value="root"/>
   <property name="password" value="masterkaoli"/>
</bean>

다른 bean 참조(References to other beans(collaborators))

ref element는 Container 안에 있는 다른 bean을 참조한다. 참조할 객체를 지정하는 방식에는 3가지가 있다.

1. bean attribute
   가장 일반적인 형태로 같은 Container 또는 부모 Container에 포함된 bean 객체를 참조한다. ‘bean’ attribute는 대상 bean의 ‘id’ 또는 여러 ’name’들 중. 하나와 같아야 한다.

   <ref bean="someBean"/>
   

2. local attribute
   같은 XML 설정 파일 내의 bean 객체를 참조한다. ’local’ attribute는 반드시 대상 bean의 ‘id’와 같아야 한다. 만약 대상 bean이 같은 XML 파일에 존재한다면. local을 사용하는 것이 좋다.

   <ref local="someBean"/>
   

3. parent attribute
   현재 Container의 부모 Container의 bean 객체를 참조한다. ‘parent’ attribute는 대상 bean의 ‘id’ 또는 여러 ’name’들 중 하나와 같아야 한다.

   <!-- in the parent context -->
   <bean id="accountService" class="com.foo.SimpleAccountService">
      <!-- insert dependencies as required as here -->
   </bean>
   

   <!-- in the child (descendant) context -->
   <bean id="accountService"  <-- notice that the name of this bean is the same as the name of the 'parent' bean
      class="org.springframework.aop.framework.ProxyFactoryBean">
      <property name="target">
          <ref parent="accountService"/>  <-- notice how we refer to the parent bean
      </property>
      <!-- insert other configuration and dependencies as required as here -->
   </bean>
   

Inner beans

<property/> 또는 <constructor-arg/> element 안에 있는 <bean/> element를 inner bean이라고 한다. Inner bean은 id나 name을 정의할 필요가 없다. 정의한다 해도 Container에서 무시하기 때문에 정의하지 않는 것이 좋다.

<bean id="outer" class="...">
   <!-- instead of using a reference to a target bean, simply define the target bean inline -->
   <property name="target">
       <bean class="com.example.Person"> <!-- this is the inner bean -->
           <property name="name" value="Fiona Apple"/>
           <property name="age" value="25"/>
       </bean>
   </property>
</bean>

Inner bean의 ‘scope’ flag와 ‘id’, ’name’은 무시된다. Inner bean의 scope은 항상 prototype이다. 따라서 inner bean을 다른 bean에 주입하는 것은 불가능한다.

Collections

Java Collection 타입인 List, Set, Map, Properties를 표현하기 위해 <list/>, <set/>, <map/>, <props/> element가 사용된다.

<bean id="moreComplexObject" class="example.ComplexObject">
   <!-- results in a setAdminEmails(java.util.Properties) call -->
   <property name="adminEmails">
       <props>
           <prop key="administrator">administrator@example.org</prop>
           <prop key="support">support@example.org</prop>
           <prop key="development">development@example.org</prop>
       </props>
   </property>
   <!-- results in a setSomeList(java.util.List) call -->
   <property name="someList">
   <list>
       <value>a list element followed by a reference</value>
       <ref bean="myDataSource" />
   </list>
   </property>
   <!-- results in a setSomeMap(java.util.Map) call -->
   <property name="someMap">
       <map>
           <entry>
               <key>
                   <value>an entry</value>
               </key>
               <value>just some string</value>
           </entry>
           <entry>
               <key>
                   <value>a ref</value>
               </key>
               <ref bean="myDataSource" />
           </entry>
       </map>
   </property>
   <!-- results in a setSomeSet(java.util.Set) call -->
   <property name="someSet">
       <set>
           <value>just some string</value>
           <ref bean="myDataSource" />
       </set>
   </property>
</bean>

map의 key와 value, set의 value의 값은 아래 element 중 하나가 될 수 있다.

bean | ref | idref | list | set | map | props | value | null

Collection 병합(Collection merging)

Container는 collection 병합 기능을 제공한다. Bean 정의 상속을 사용하여 부모 bean 정의의 <list/>, <map/>, <set/>, <props/> element와 자식 bean 정의의 <list/>, <map/>, <set/>, <props/> element를 병합할 수 있다.

<beans>
<bean id="parent" abstract="true" class="example.ComplexObject">
   <property name="adminEmails">
       <props>
           <prop key="administrator">administrator@example.com</prop>
           <prop key="support">support@example.com</prop>
       </props>
   </property>
</bean>
<bean id="child" parent="parent">
   <property name="adminEmails">
       <!-- the merge is specified on the *child* collection definition -->
       <props merge="true">
           <prop key="sales">sales@example.com</prop>
           <prop key="support">support@example.co.uk</prop>
       </props>
   </property>
</bean>
<beans>

위 설정에 따라 생성된 child bean 객체의 adminEmails는 아래와 같은 값을 가진다.

administrator=administrator@example.com
sales=sales@example.com
support=support@example.co.uk

Nulls

null 값을 사용하기 위해서 <null/> element를 사용한다. Spring는 argument가 없을 경우 빈 문자열(””)로 인식한다.

<bean class="ExampleBean">
   <property name="email"><value/></property>
</bean>

위 설정에 따르면, email의 값은 ”“이다. 다음은 null값을 갖는 예제이다.

<bean class="ExampleBean">
   <property name="email"><null/></property>
</bean>

간편한 설정 방법(Shortcuts and other convenience options for XML-based configuration metadata)

XML-based configuration metadata shortcuts

<property/>, <constructor-arg/>, <entry/> element는 모두 <value/> element 대신에 ‘value’ attribute를 사용할 수 있다.

<property name="myProperty">
   <value>hello</value>
</property>

<constructor-arg>
   <value>hello</value>
</constructor-arg>

<entry key="myKey">
   <value>hello</value>
</entry>

위 설정은 아래와 동일한 설정이다.

<property name="myProperty" value="hello"/>

<constructor-arg value="hello"/>

<entry key="myKey" value="hello"/>

<property/>, <constructor-arg/> element는 <ref/> element 대신에 ‘ref’ attribute를 사용할 수 있다.

<property name="myProperty">
   <ref bean="myBean">
</property>

<constructor-arg>
   <ref bean="myBean">
</constructor-arg>

위 설정은 아래와 동일한 설정이다.

<property name="myProperty" ref="myBean"/>

<constructor-arg ref="myBean"/>

단, shortcut은 <ref bean=“xxx”>와 동일하다. <ref local=“xxx”>에 해당하는 shortcut은 없다.

<entry/> element는 ‘key’ / ‘key-ref’와 ‘value’ / ‘value-ref’ attribute를 사용할 수 있다.

<entry>
   <key>
       <ref bean="myKeyBean" />
   </key>
   <ref bean="myValueBean" />
</entry>

위 설정은 아래와 같은 설정이다.

<entry key-ref="myKeyBean" value-ref="myValueBean"/>

The p-namespace and how to use it to configure properties

‘’<property/>’’ element 대신 “p-namespace”를 사용하여 XML 설정을 작성할 수 있다. 아래 classic bean과 p-namespace bean은 동일한 Bean 설정이다.

<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:p="http://www.springframework.org/schema/p"
   xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans.xsd">
 
   <bean name="classic" class="com.example.ExampleBean">
       <property name="email" value="foo@bar.com/>
   </bean>
 
   <bean name="p-namespace"
       class="com.example.ExampleBean"
       p:email="foo@bar.com"/>
</beans>

아래 예제는 다른 bean 객체의 참조를 삽입하는 예제이다. Attribute 이름 끝에 ‘-ref’를 붙이면 참조로 인식한다.

<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:p="http://www.springframework.org/schema/p"
   xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans.xsd">
 
   <bean name="john-classic" class="com.example.Person">
       <property name="name" value="John Doe"/>
       <property name="spouse" ref="jane"/>
   </bean>
 
   <bean name="john-modern" 
       class="com.example.Person"
       p:name="John Doe"
       p:spouse-ref="jane"/>
 
   <bean name="jane" class="com.example.Person">
       <property name="name" value="Jane Doe"/>
   </bean>
</beans>

Compound property names

복합 형식의 property 이름도 사용 가능하다.

<bean id="foo" class="foo.Bar">
   <property name="fred.bob.sammy" value="123" />
</bean>

foo bean은 fred property를 가지고, fred property는 bob property를 가진다. 그리고 bob property는 sammy property를 가지고, 마지막 sammy property가 123을 값으로 가진다. 이 작업이 정상적으로 동작하려면 bean이 생성되었을 때, foo의 fred property, fred의 bob property는 반드시 null이 아니어야 한다. 그렇지 않을 경우 NullPointerException이 발생한다.

depends-on 사용(Using depends-on)

대부분의 경우, bean들간의 종속성은 ‘’<ref/>’’ element에 의해 표현된다. 하지만 드물게 이런 종속성이 직접 나타나지 않는 경우도 있다(예를 들면, database driver 등록처럼 static 메소드에 의해 초기화되어야 하는 경우 등). 이런 경우 ‘depends-on’ attribute를 사용하여 명시적으로 종속성을 표현할 수 있다.

<bean id="beanOne" class="ExampleBean" depends-on="manager"/>
 
<bean id="manager" class="ManagerBean" />

만약 다수의 bean에 대한 종속성을 표현하고 하는 경우에는, ‘depends-on’ attribute의 값으로 bean 이름을 나열하면 된다. bean 이름의 구분자로는 콤마(’,’), 공백문자(’ ‘), 세미콜론(’;’) 등을 사용할 수 있다.

<bean id="beanOne" class="ExampleBean" depends-on="manager,accountDao">
   <property name="manager" ref="manager" />
</bean>
 
<bean id="manager" class="ManagerBean" />
<bean id="accountDao" class="x.y.jdbc.JdbcAccountDao" />

늦은 객체화(Lazily-instantiated beans)

ApplicationContext는 시작시에 모든 singleton bean을 선객체화(pre-instantiate)한다. 선객체화(pre-instantiate)는 초기화 과정에서 모든 singleton baen을 생성하고 설정한다는 것을 의미한다. 일반적으로 선객체화가 좋은 방식인데, 왜냐하면 잘못된 설정이 있는 경우, 즉시 발견할 수 있기 때문이다.

어쨌거나, 이런 방식을 원하지 않을 경우도 있다. 만약 ApplicationContext에 의해 선 객체화 되는 singleton bean을 원하지 않을 경우, 선택적으로 bean 정의에 늦은 객체화(lazy-initailized)를 설정할 수 있다. 늦은 객체화(lazy-initailized)로 설정된 bean은 시작 시에 생성되는 것이 아니라, 처음으로 필요로 했을 때 생성된다.

XML 설정에서는 ‘’<bean/>’’ element의 ’lazy-init’ attribute를 사용한다.

<bean id="lazy" class="com.foo.ExpensiveToCreateBean" lazy-init="true"/>
 
<bean name="not.lazy" class="com.foo.AnotherBean"/>

늦은 객체화에 대해서 이해하고 있어야 하는 것은, 만약 늦은 객체화로 설정된 bean에 대해서 그렇지 않은 singleton bean이 종속성을 가지고 있다면, ApplicationContext는 시작 시에 singleton bean이 종속하고 있는 모든 bean을 생성한다는 것이다. 즉, 명시적으로 늦은 객체화로 선언한 bean이라도 시작 시에 생성될 수 있다.

그리고, <beans/> element의 ‘default-lazy-init’ attribute를 사용하여 Container 레벨에서의 늦은 객체화를 설정할 수 있다.

<beans default-lazy-init="true">
   <!-- no beans will be pre-instantiated... -->
</beans>

자동엮기(Autowiring collaborators)

Spring Container는 서로 관계된 bean들을 자동으로 엮어(autowire)줄 수 있다. 자동엮기(autowiring)는 각각의 bean 단위로 설정된다. 자동엮기(autowiring) 기능을 사용하면 property나 생성자 argument를 지정할 필요가 없어지므로, 타이핑일 줄일 수 있다. 자동엮기(autowiring)에는 5가지 모드가 있으며, XML 기반 설정에서는 <bean/> element의 ‘autowire’ attribute를 사용하여 설정할 수 있다.

만약 종속성을 property나 constructor-arg를 사용하여 명시적으로 설정한 경우, 자동엮기(autowiring) 설정은 무시된다.

Bean을 자동엮기 대상에서 제외하는 방법(Excluding a bean from being available from autowiring

<bean/> element의 ‘autowire-candidate’ attribute 값을 ‘false’로 설정함으로써, 대상 bean이 다른 bean에 의해 자동엮임을 당하는 것을 방지할 수 있다.

종속성 검사(Checking for dependencies)

Spring IoC Container는 bean의 미해결 종속성의 존재를 검사할 수 있다. 이 기능은 bean의 모든 property가 지정되었는지는 확인하고 싶을 때 유용하다. 종속성 검자(Dependency checking) 기능은 자동엮기(autowiring) 기능과 마찬가지로 각각의 bean마다 설정할 수 있다. 종속성 검사에는 4가지 모드가 있으며, XML 기반 설정에서는 <bean/> element의 ‘dependency-check’ attribute를 사용하여 설정할 수 있다.

메소드 삽입(Method Injection)

대부분의 어플리케이션에서, Container에 존재하는 대부분의 bean은 singleton이다. Singleton bean이 다른 singleton bean과 협력(collaborate)하거나, non-singleton bean이 다른 non-singleton bean과 협력하는 경우, 가장 일반적인 방법은 bean의 property를 정의함으로써 종속성을 조절하는 것이다. 하지만 만약 관련된 bean들의 생명주기가 다른 경우 문제가 발생한다. Singleton bean A가 non-singleton bean B를 사용한다고 할 때, Container는 singleton bean A를 단지 한번만 생성할 것이고, 따라서 property도 역시 한번만 설정될 것이다. Container는 bean B가 필요한 매 순간 새로운 객체를 생성하여 bean A에게 제공해야 하지만, 그럴 수 있는 방법이 없다.

위 문제에 대한 한가지 해법은 몇몇 제어의 역전(inversion of control)를 버리는 것이다. Bean A는 BeanFactoryAware interface를 구현함으로써 자신이 속한 Container를 알 수 있다. 그리고 bean B의 객체가 필요한 순간에 Container의 getBean(“B”)을 호출함으로써 bean B의 객체를 가져올 수 있다.

// a class that uses a stateful Command-style class to perform some processing
package fiona.apple;

// lots of Spring-API imports
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.BeanFactoryAware;

public class CommandManager implements BeanFactoryAware {
   private BeanFactory beanFactory;

   public Object process(Map commandState) {
       // grab a new instance of the appropriate Command
       Command command = createCommand();
       // set the state on the (hopefully brand new) Command instance
       command.setState(commandState);
       return command.execute();
   }

   // the Command returned here could be an implementation that executes asynchronously, or whatever
   protected Command createCommand() {
       return (Command) this.beanFactory.getBean("command"); // notice the Spring API dependency
   }

   public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
       this.beanFactory = beanFactory;
   }
}

위 예제는 일반적으로는 바람직하지 않은 솔루션이다. 왜냐하면 업무 코드(business code)는 Spring Framework과 관련될 필요가 없기 때문이다. 메소드 삽입(Method Injection)은 이런 경우를 말끔히 해결할 수 있는 방법이다.

Lookup 메소드 삽입(Lookup method injection)

Lookup 메소드 삽입은 Container가 관리하고 있는 bean의 메소드를 덮어써서(override) Container 안에 있는 다른 bean을 찾을 수 있게 하는 기능이다. Spring Framework는 메소드 삽입을 구현하기 위해서 CGLIB 라이브러리를 사용하여 동적으로 상속클래스를 생성한다.

package fiona.apple;

// no more Spring imports! 
public abstract class CommandManager {
   public Object process(Object commandState) {
       // grab a new instance of the appropriate Command interface
       Command command = createCommand();
       // set the state on the (hopefully brand new) Command instance
       command.setState(commandState);
       return command.execute();
   }

   // okay... but where is the implementation of this method?
   protected abstract Command createCommand();
}

삽입될 메소드는 반드시 다음과 같은 형태를 가져야 한다.

<public|protected> [abstract] <return-type> theMethodName(no-arguments);

만약 메소드가 abstract이면, 동적으로 생성된 서브클래스는 메소드를 구현할 것이다. 만약 그렇지 않으면 동적으로 생성된 서브클래스를 원본 클래스의 메소드를 덮어쓸(override) 것이다.

<!-- a stateful bean deployed as a prototype (non-singleton) -->
<bean id="command" class="fiona.apple.AsyncCommand" scope="prototype">
   <!-- inject dependencies here as required -->
</bean>
 
<!-- commandProcessor uses statefulCommandHelper -->
<bean id="commandManager" class="fiona.apple.CommandManager">
   <lookup-method name="createCommand" bean="command"/>
</bean>

commandManager는 command bean의 새로운 객체가 필요할 때마다 자신의 createCommand() 메소드를 호출할 것이다. 만약 command bean이 prototype이 아닌 singleton인 경우, createCommand 메소드는 같은 객체를 리턴할 것이다.

동적 서브클래스 생성이 동작하려면 classpath에 CGLIB가 추가되어 있어야 한다. 그리고 원본 class는 final이면 안되며, 덮어쓸(override) 메소드 역시 final이면 안된다.

참고자료

• Spring Framework - Reference Document / 1.4 Dependencies

2.4 - Bean Scopes

Bean scope

개요

Bean 정의는 실제 Bean 객체를 생성하는 방식을 정의하는 것으로 Class와 마찬가지로 하나의 Bean 정의에 해당하는 다수의 객체가 생성될 수 있다.
Bean 정의를 통해 객체에 다양한 종속성 및 설정값을 주입할 수 있을 뿐 아니라, 객체의 범위(Scope)를 정의할 수 있다.

설명

Spring 프레임워크는 6개의 Scope를 지원하며, 이 중 4개의 Scope는 Web-aware ApplicationContext를 사용하는 경우에만 사용할 수 있다. 또한, 사용자 정의 범위를 생성할 수도 있다.

The singleton scope

Bean이 singleton인 경우, 단지 하나의 공유 객체만 관리된다.

Singleton scope은 Spring의 기본(default) scope이다.

<bean id="accountService" class="com.something.DefaultAccountService"/>
 
<!-- the following is equivalent, though redundant (singleton scope is the default) -->
<bean id="accountService" class="com.something.DefaultAccountService" scope="singleton"/>

The prototype scope

Singleton이 아닌 prototype scope의 형태로 정의된 bean은 필요한 매 순간 새로운 bean 객체가 생성된다.

<bean id="accountService" class="com.something.DefaultAccountService" scope="prototype"/>

Prototype scope을 사용할 때 염두에 두고 있어야 할 것이 있다.
Spring은 prototype bean의 전체 생명주기를 관리하지 않는데 Container는 객체화하고, 값을 설정하고, 다른 prototype 객체와 조립하여 Client에게 전달한 후 더 이상 prototype 객체를 관리하지 않는다.
즉, scope에 관계없이 초기화(initialization) 생명주기 callback 메소드가 호출되는 반면에, prototype의 경우 파괴(destruction) 생명주기 callback 메소드는 호출되지 않는다.
이것은 client 코드가 prototype 객체를 clean up하고 prototype 객체가 들고 있던 리소스를 해제하는 책임을 가진다는 것을 의미한다.

Prototype bean에 종속적인 singleton bean(Singleton beans with prototype-bean dependencies)

이 문제는 메소드 삽입(Method Injection)에서 다루고 있다.

기타 scopes(The other scopes)

request, session, application, websocket scope들은 반드시 web-based 어플리케이션에서 사용할 수 있다.

기본 Web 설정(Initial web configuration)

request, session, application, websocket scope을 사용하기 위해서는 추가적인 설정이 필요하다. 추가 설정은 사용할 Servlet 환경에 따라 달라진다.
만약 Spring Web MVC 안에서 bean에 접근할 경우, 즉 Spring DispatcherServlet 또는 DispatcherPortlet에서 처리되는 요청인 경우, 별도의 추가 설정은 필요없다.( DispatcherServlet과 DispatcherPortlet은 이미 모든 관련있는 상태를 제공한다.)
만약 Servlet 2.4+ web Container를 사용하고, JSF나 Struts 등과 같이 Spring의 DispatcherServlet의 외부에서 요청을 처리하는 경우, 다음 javax.servlet.ServletRequestListener를 ‘web.xml’ 파일에 추가해야 한다.

<web-app>
   ...
   <listener>
       <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
   </listener>
   ...
</web-app>

만약 다른 오래된 web Container(Servlet 2.3)를 사용한다면, 제공되는 javax.servlet.Filter 구현체를 사용해야 한다.(filter mapping은 web 어플리케이션 설정에 따라 달라질 수 있으므로, 적절히 수정해야 한다.)

<web-app>
   ..
   <filter>
       <filter-name>requestContextFilter</filter-name>
       <filter-class>org.springframework.web.filter.RequestContextFilter</filter-class>
   </filter>
   <filter-mapping>
       <filter-name>requestContextFilter</filter-name>
       <url-pattern>/*</url-pattern>
   </filter-mapping>
   ...
</web-app>

The request scope

<bean id="loginAction" class="com.foo.LoginAction" scope="request"/>

위 정의에 따라, Spring Container는 모든 HTTP request에 대해서 ’loginAction’ bean 정의에 대한 LoginAction 객체를 생성할 것이다. 즉, ’loginAction’ bean은 HTTP request 수준에 한정된다(scoped). 요청에 대한 처리가 완료되었을 때, 한정된(scoped) bean도 폐기된다.

The session scope

<bean id="userPreferences" class="com.foo.UserPreferences" scope="session"/>

위 정의에 따라, Spring Container는 하나의 HTTP Session 일생동안 ‘userPreferences’ bean 정의에 대한 UserPreferences 객체를 생성할 것이다. 즉, ‘userPreferences’ bean은 HTTP Session 수준에 한정된다(scoped). HTTP Session이 폐기될 때, 한정된(scoped) bean로 폐기된다.

The application scope

<bean id="appPreferences" class="com.foo.AppPreferences" scope="application"/>

위 정의에 따라, Spring Container는 전체 Web Application에 대해 ‘appPreferences’ bean 정의에 대한 AppPreferences 객체를 생성할 것이다. singleton scope와 비슷하지만 bean의 scope와 관련하여 매우 중요한 차이가 있는데, bean이 application 범위인 경우 bean의 동일한 instance는 동일한 ServletContext에서 실행되는 여러 서블릿 기반 애플리케이션에서 공유되는 반면 singleton 범위의 bean은 단일 애플리케이션 컨텍스트로만 범위가 지정된다.

The websocket scope

<bean id="appPreferences" class="com.foo.AppPreferences" scope="websocket"/>

WebSocket scope bean은 WebSocket 세션 속성에 저장된다. 그리고 전체 WebSocket 세션 동안 해당 bean에 액세스할 때마다 bean의 동일한 instance가 반환된다.

한정적 bean에 대한 종속성(Scoped beans as dependencies)

HTTP request 또는 Session에 한정적인(scoped) bean을 정의하는 것은 꽤 괜찮은 기능이지만 Spring IoC Container가 제공하는 핵심 기능은 객체를 생성하는 것 뿐만 아니라 엮어준다는 것이다. 만약 HTTP request에 한정적인(scoped) bean을 다른 bean에 주입하기를 원한다면, 한정적(scoped) bean 대신에 AOP Proxy를 주입해야 한다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:aop="http://www.springframework.org/schema/aop"
   xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans.xsd
       http://www.springframework.org/schema/aop
       http://www.springframework.org/schema/aop/spring-aop.xsd">
 
   <!-- a HTTP Session-scoped bean exposed as a proxy -->
   <bean id="userPreferences" class="com.foo.UserPreferences" scope="session">
       <!-- this next element effects the proxying of the surrounding bean -->
       <aop:scoped-proxy/>
   </bean>
 
   <!-- a singleton-scoped bean injected with a proxy to the above bean -->
   <bean id="userService" class="com.foo.SimpleUserService">
       <!-- a reference to the proxied 'userPreferences' bean -->
       <property name="userPreferences" ref="userPreferences"/>
   </bean>
</beans>

Proxy를 생성하기 위해서 <aop:scoped-proxy/> element를 scoped bean 정의에 추가해야 한다(CGLIB 라이브러리도 classpath에 추가해야 한다).

참고자료

• Spring Framework - Reference Document / 1.5 Bean scopes

2.5 - Customizing the nature of a Bean

Customizing the nature of a bean

개요

컨테이너의 빈 라이프사이클 관리와 상호 작용하기 위해 Spring InitializingBean 및 DisposableBean 인터페이스를 구현할 수 있는데, 컨테이너는 전자의 경우 afterPropertiesSet()을 호출하고 후자의 경우 destroy()를 호출하여 빈이 초기화 및 소멸될 때 특정 작업을 수행하도록 한다.

설명

Lifecycle callbacks

Spring Framework는 Container 내부의 bean의 행동을 변화시길 수 있는 다양한 callback interface를 제공한다.

객체화 callbacks(Initialization callbacks)

org.springframework.beans.factory.InitializingBean interface를 구현하면 bean에 필요한 모든 property를 설정한 후, 초기화 작업을 수행한다. InitializingBean interface는 다음 메소드를 명시하고 있다.

void afterPropertiesSet() throws Exception;

일반적으로, InitializingBean interface의 사용을 권장하지 않는다. 왜냐하면 code가 불필요하게 Spring과 결합되기(couple) 때문이다. 대안으로, bean 정의는 초기화 메소드를 지정할 수 있다. XML 기반 설정의 경우, ‘init-method’ attribute를 사용한다.

<bean id="exampleInitBean" class="examples.ExampleBean" init-method="init"/>

public class ExampleBean {
   public void init() {
       // do some initialization work
   }
}

위 예제는 아래 예제와 같다.

<bean id="exampleInitBean" class="examples.AnotherExampleBean"/>

public class AnotherExampleBean implements InitializingBean {
   @Override
   public void afterPropertiesSet() {
       // do some initialization work
   }
}

파괴 callbacks(Destruction callbacks)

org.springframework.beans.factory.DisposableBean interface를 구현하면, Container가 파괴될 때 bean이 callback를 받을 수 있다. DisposableBean interface는 다음 메소드를 명시하고 있다.

void destroy() throws Exception;

일반적으로, DisposableBean interface의 사용을 권장하지 않는다. 왜냐하면 code가 불필요하게 Spring과 결합되기(couple) 때문이다. 대안으로, bean 정의는 초기화 메소드를 지정할 수 있다. XML 기반 설정의 경우, ‘destroy-method’ attribute를 사용한다.

<bean id="exampleInitBean" class="examples.ExampleBean" destroy-method="cleanup"/>

public class ExampleBean {
   public void cleanup() {
       // do some destruction work (like releasing pooled connections)
   }
}

위 예제는 아래 예제와 같다.

<bean id="exampleInitBean" class="examples.AnotherExampleBean"/>

public class AnotherExampleBean implements DisposableBean {
   @Override
   public void destroy() {
       // do some destruction work (like releasing pooled connections)
   }
}

기본 객체화 및 파괴 메소드(Default initialization & destroy methods)

Spring Container는 모든 bean에 대해서 같은 이름의 초기화 및 파괴 메소드를 지정할 수 있다.

public class DefaultBlogService implements BlogService {
   private BlogDao blogDao;

   public void setBlogDao(BlogDao blogDao) {
       this.blogDao = blogDao;
   }

   // this is (unsurprisingly) the initialization callback method
   public void init() {
       if (this.blogDao == null) {
           throw new IllegalStateException("The [blogDao] property must be set.");
       }
   }
}

<beans default-init-method="init">
   <bean id="blogService" class="com.foo.DefaultBlogService">
       <property name="blogDao" ref="blogDao" />
   </bean>
</beans>

<beans/> element의 ‘default-init-method’ attribute를 이용하여 기본 객체화 callback 메소드를 지정할 수 있다. 파괴 callback 메소드의 경우 ‘default-destroy-method’ attribute를 이용하여 지정할 수 있다.

<bean/> element에 ‘init-method’, ‘destroy-method’ attribute가 정의되어 있는 경우, 기본값은 무시된다.

생명주기 메커니즘 병합

Spring Framework에서는 3가지 방식의 생명주기 메커니즘이 존재한다: InitialzingBean과 DisposableBean interface; 맞춤 init()과 destroy() 메소드; 그리고 @PostConstruct and @PreDestroy annotations

만약 서로 다른 생명주기 메커니즘을 같이 사용할 경우, 개발자는 적용되는 순서를 알고 있어야 한다. 객체화 메소드의 순서는 다음과 같다.

1. @PostConstruct annotation이 있는 메소드

2. InitializingBean callback interface에 정의된 afterPropertiesSet()

3. 맞춤 init() 메소드

파괴 메소드의 호출 순서는 다음과 같다.

1. @PreDestroy annotation이 있는 메소드

2. DisposableBean callback interface에 정의된 destroy()

3. 맞춤 destroy() 메소드

시작 및 종료 callbacks(Startup and Shutdown Callbacks)

Lifecycle 인터페이스는 자체 수명 주기 요구 사항(예: 일부 백그라운드 프로세스 시작 및 중지)이 있는 모든 객체에 대해 필수 메서드를 정의할 수 있다.

public interface Lifecycle {
   void start();
 
   void stop();
 
   boolean isRunning();
}

모든 Spring 관리 객체는 Lifecycle 인터페이스를 구현할 수 있다. 그런 다음 애플리케이션 컨텍스트 자체가 시작 및 중지 신호를 수신하면(예: 런타임에 중지/재시작 시나리오의 경우) 해당 컨텍스트 내에 정의된 모든 Lifecycle 구현으로 해당 호출을 캐스케이드한다.

public interface LifecycleProcessor extends Lifecycle {
   void onRefresh();
 
   void onClose();
}

참고자료

• Spring Framework - Reference Document / 1.6 Customizing the nature of a bean

2.6 - Bean Definition Profiles

Bean Definition Profiles

개요

Bean의 Profile은 Spring f/w ver. 3.1부터 추가되었으며 동일한 id의 bean을 여러 개 정의하여 사용자의 설정으로 활성화시킨 Profile의 해당 bean이 Runtime시에 동작하도록 하는 기능이다. 보통 개발시점과 운영시점에 bean의 Profile설정 변경만으로 Spring Container에서 Bean적용이 달리 적용되도록 하는데 쓰인다.

Profile설정 시, 반드시 Profile을 활성화해야만 사용가능하다. 만약 Profile만 설정하고 활성화하지 않으면 Exeption(NoSuchBeanDefinitionException)이 발생한다.

설명

아래에서 Profile을 설정하는 방법과 Profile을 활성화(Active Profile)하는 방법에 대하여 알아본다.

Profile 설정 방법

Profile의 설정방법에는 XML설정과 Annotation설정으로 나뉜다.

XML Profile설정

기존의 전형적인 XML Bean설정에 대하여 알아보고 새로 추가된 Profiles설정에 대하여 살펴본다. 동일한 Bean id를 Profile별로 XML에 설정하는 방법에는 XML을 나누는 방법, 하나의 XML에서 관리하는 방법이 있다

A typical XML Configuration

기존에는 Bean id설정은 반드시 유일해야 하며 Bean설정을 변경하기 위해서는 다른 id를 가진 Bean을 새로 설정하거나 동일 Bean의 내부설정을 변경해주어야했다.

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jdbc="http://www.springframework.org/schema/jdbc"
    xsi:schemaLocation="...">
 
    <bean id="transferService" class="com.bank.service.internal.DefaultTransferService">
        <constructor-arg ref="accountRepository"/>
        <constructor-arg ref="feePolicy"/>
    </bean>
 
    <bean id="accountRepository" class="com.bank.repository.internal.JdbcAccountRepository">
        <constructor-arg ref="dataSource"/>
    </bean>
 
    <bean id="feePolicy" class="com.bank.service.internal.ZeroFeePolicy"/>
 
    <jdbc:embedded-database id="dataSource">
        <jdbc:script location="classpath:com/bank/config/sql/schema.sql"/>
        <jdbc:script location="classpath:com/bank/config/sql/test-data.sql"/>
    </jdbc:embedded-database>
</beans>

1. Bean Profiles - Xml을 분리하여 설정하는 방법

<transfer-service-config.xml>

아래는 “dataSource” bean을 사용하는 “accountRepository” bean 설정한 XML이다. 어떤 Profile의 bean인지 여부와 상관없이 Spring container기동시점에는 dataSource라는 bean id를 가진 유일한 bean을 가져오기 때문에 이전 설정과 똑같이 bean id값만 쓰면 된다.

<beans ...>
    <bean id="transferService" ... />
 
    <bean id="accountRepository" class="com.bank.repository.internal.JdbcAccountRepository">
        <constructor-arg ref="dataSource"/>
    </bean>
 
    <bean id="feePolicy" ... />
</beans>

<standalone-datasource-config.xml>

개발시점에 사용하는 “dataSource” bean을 정의하는 XML. Profile명은 “dev"로 정의하고 있으며 Embedded DB를 DataSource로 설정하고 있다. “dev” Profile을 활성화시키면 해당Bean이 동작한다.

<beans profile="dev">
    <jdbc:embedded-database id="dataSource">
        <jdbc:script location="classpath:com/bank/config/sql/schema.sql"/>
        <jdbc:script location="classpath:com/bank/config/sql/test-data.sql"/>
    </jdbc:embedded-database>
</beans>

<jndi-datasource-config.xml>

운영시점에 사용하는 “dataSource” bean을 정의하는 XML. Profile명은 “production"으로 정의하고 있으며 JDNI를 DataSource로 설정하고 있다. “production” Profile을 활성화시키면 해당 Bean이 동작한다.

<beans profile="production">
    <jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/datasource"/>
</beans>

2. Bean Profiles - XML을 한 파일에서 설정

<beans> element를 하나의 XML파일에서 profile값과 함께 여러 번 정의할 수도 있다.

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jdbc="http://www.springframework.org/schema/jdbc"
    xmlns:jee="http://www.springframework.org/schema/jee"
    xsi:schemaLocation="...">
 
    <bean id="transferService" class="com.bank.service.internal.DefaultTransferService">
        <constructor-arg ref="accountRepository"/>
        <constructor-arg ref="feePolicy"/>
    </bean>
 
    <bean id="accountRepository" class="com.bank.repository.internal.JdbcAccountRepository">
        <constructor-arg ref="dataSource"/>
    </bean>
    <bean id="feePolicy" class="com.bank.service.internal.ZeroFeePolicy"/>
    <beans profile="dev">
        <jdbc:embedded-database id="dataSource">
            <jdbc:script location="classpath:com/bank/config/sql/schema.sql"/>
            <jdbc:script location="classpath:com/bank/config/sql/test-data.sql"/>
        </jdbc:embedded-database>
    </beans>
    <beans profile="production">
        <jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/datasource"/>
    </beans>
</beans>

Annotation Profile설정

Profile의 Annotation설정은 @Profile을 통해서 설정 가능하다. @Configuration과 함께 @Profile(“Profile명”)을 클래스에 쓰게 되면 내부 메소드에 붙은 @Bean을 통해 Bean들이 등록된다.

기존 @Configuration class에 대하여 살펴보고 @Profile을 통해 Bean을 설정하는 방법에 대하여 살펴본다.

A typical @Configuration Class

Class위에 @Configuration을 붙이면 @Bean과 함께 정의한 메소드 명이 bean id로 등록된다.

@Configuration
public class TransferServiceConfig {
 
    @Bean
    public TransferService transferService() {
        return new DefaultTransferService(accountRepository(), feePolicy());
    }
 
    @Bean
    public AccountRepository accountRepository() {
        return new JdbcAccountRepository(dataSource());
    }
 
    @Bean
    public FeePolicy feePolicy() {
        return new ZeroFeePolicy();
    }
 
    @Bean
    public DataSource dataSource() {
        return new EmbeddedDatabaseBuilder()
            .setType(EmbeddedDatabaseType.HSQL)
            .addScript("classpath:com/bank/config/sql/schema.sql")
            .addScript("classpath:com/bank/config/sql/test-data.sql")
            .build();
    }
}

@Profile 설정

위에서 살펴봤던 Bean Profile XML 설정을 Annotation(@Profile)으로 설정하면 다음과 같다. @Profile은 XML의 beans profile의 설정과 똑같이 동작하며 @Bean은 XML의 bean설정과 매칭된다.

다음은 “dev” Profile을 정의했을 때의 Java코드이다. Profile명이 dev인 “dataSource” Bean을 정의하고 있다.

@Configuration
@Profile("dev")
public class StandaloneDataConfig {
    @Bean
    public DataSource dataSource() {
        return new EmbeddedDatabaseBuilder()
            .setType(EmbeddedDatabaseType.HSQL)
            .addScript("classpath:com/bank/config/sql/schema.sql")
            .addScript("classpath:com/bank/config/sql/test-data.sql")
            .build();
    }
}

다음은 “production” Profile을 정의했을 때의 Java코드이다. Profile명이 production인 “dataSource” Bean을 정의하고 있다.

@Configuration
@Profile("production")
public class JndiDataConfig {
 
    @Bean
    public DataSource dataSource() throws Exception {
        Context ctx = new InitialContext();
        return (DataSource) ctx.lookup("java:comp/env/jdbc/datasource");
    }
}

Profile 활성화 (Active Profile)

설정한 Profile을 활성화 하는 방법에는 선언적인 Profile활성화, Java코드를 통한 Profile활성화가 있다.

1. 선언적인 Profile 활성화(web.xml, 환경변수, 프로퍼티 등..)

web.xml 또는 JVM실행 시 환경변수, Property값 등으로 Profile을 활성화시킬 수 있다. Java코드를 통해서도 가능하나 실행환경이 war파일로 제공되거나 배포시점의 경우에는 관리의 불편함이 있으므로 web.xml을 통한 Profile활성화를 추천한다.

<web.xml로 Profile활성화>

<servlet>
      <servlet-name>dispatcher</servlet-name>
      <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
      <init-param>
          <param-name>spring.profiles.active</param-name>
          <param-value>production</param-value>
      </init-param>
  </servlet>

<JVM실행 시 환경변수로 Profile활성화>

java -Dspring.profiles.active="production"

2. Java 코드를 통한 Profile 활성화

Spring 3.1부터 Environment라는 인터페이스를 통해서 해당프로파일을 활성화시킬 수 있다.

<XML로 profile을 설정한 경우, Java코드로 Profile활성화> Profile명이 dev로 설정되어있는 bean을 활성화시킨다. GenericXmlApplicationContext에서 가져온 Environment를 통해 setActiveProfiles메소드로 Profile을 활성화시키고 해당 configuration xml을 로딩한다.

다음 예시에서는 Profile명이 production로 설정되어있는 bean이 활성화되며 Profile명이 dev으로 설정되어있는 bean은 Skip된다.

GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
ctx.getEnvironment().setActiveProfiles("production");
ctx.load("classpath:/com/bank/config/xml/*-config.xml");
ctx.refresh();

<@Profile로 Profile을 설정한 경우, Java코드로 Profile활성화 > 활성화하고자하는 Profile명을 setActiveProfiles메소드로 활성화시키고 “com.bank.config.code"패키지 내의 모든 @Configuration class를 스캔한다. Profile이 dev로 설정되어있는 bean이 활성화되며 Profile이 Production으로 설정되어있는 bean은 Skip된다.

AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
ctx.getEnvironment().setActiveProfiles("dev");
ctx.scan("com.bank.config.code"); // find and register all @Configuration classes within
ctx.refresh();

3. JUnit4테스트의 @ActiveProfile 어노테이션을 통한 Profile활성화

JUnit4에서 Test class에 @ActiveProfile을 붙임으로써 Profile활성화가 가능하다. @ContextConfiguration과 함께 쓰며, @ActiveProfile뒤에 Profile명을 붙이면 해당 Profile이 활성화된다.

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(loader=AnnotationConfigContextLoader.class)
@ActiveProfiles("annotationProfile")
public class SpringAnnotationProfileTest {
}

참고자료

• Spring Framework - Reference Document / 3.2 Bean Definition Profiles
• Spring team blog - XML profiles
• Spring team blog - introducing @Profile

2.7 - Bean Definition Inheritance

Bean definition inheritance

개요

Bean 정의는 많은 양의 설정 정보를 포함하고 있다. 자식 bean 정의는 부모 bean 정의로부터 설정 정보를 상속받은 bean 정의를 의미한다. 자식 bean 정의는 필요에 따라 부모 bean 정의로부터 상속받은 설정 정보를 덮어쓰거나 추가할 수 있다.

설명

XML 기반 설정에서는 자식 bean 정의에 ‘parent’ attribute를 사용하여 상속관계를 정의할 수 있다.

<bean id="inheritedTestBean" abstract="true"
       class="org.springframework.beans.TestBean">
   <property name="name" value="parent"/>
   <property name="age" value="1"/>
</bean>
 
<bean id="inheritsWithDifferentClass"
       class="org.springframework.beans.DerivedTestBean"
       parent="inheritedTestBean" init-method="initialize">
   <property name="name" value="override"/>
   <!-- the age property value of 1 will be inherited from  parent -->
</bean>

자식 bean 정의는 bean class가 명기되어 있지 않을 경우, 부모 bean 정의의 값을 사용한다. 만약 자식 bean 정의에 bean class가 명기되어 있는 경우, 자식 bean 정의의 bean class는 부모 bean 정의의 모든 property 값을 받아들일 수 있어야 한다.

자식 bean 정의는 부모 bean 정의의 생성자 argument 값, property 값, 그리고 메소드 덮어씀을 상속받는다. 만약 init-method, destroy-method, static factory 메소드 설정이 명기되어 있을 경우, 부모의 설정을 덮어쓴다.

다음 설정은 항상 자식 bean 정의의 값을 따른다: depends on, autowire mode, dependency check, singleton, scope, lazy init.

부모 bean 정의는 abstract attribute를 사용하여 abstract로 설정할 수 있다. 이 경우, 부모 bean 정의는 class를 지정하지 않는다.

<bean id="inheritedTestBeanWithoutClass" abstract="true">
   <property name="name" value="parent"/>
   <property name="age" value="1"/>
</bean>
 
<bean id="inheritsWithClass" class="org.springframework.beans.DerivedTestBean"
       parent="inheritedTestBeanWithoutClass" init-method="initialize">
   <property name="name" value="override"/>
   <!-- age will inherit the value of 1 from the parent bean definition-->
</bean>

부모 bean 정의는 완전하지 않기 때문에 객체화 될 수 없다.

참고자료

• Spring Framework - Reference Document / 1.7 Bean definition inheritance

2.8 - Container Extension Points

Container extension points

개요

Spring Framework의 IoC 컴포넌트는 확장을 고려하여 설계되었다. 일반적으로 어플리케이션 개발자가 다양한 BeanFactory 또는 ApplicationContext 구현 클래스를 상속받을 필요는 없다.
Spring IoC Container는 특별한 통합 interface의 구현체를 삽입하여 확장할 수 있다.

설명

BeanPostProcessors를 사용한 확장(Customizing beans using BeanPostProcessors)

BeanPostProcessors interface는 다수의 callback 메소드를 정의하고 있는데, 어플리케이션 개발자는 이들 메소드를 구현함으로써 자신만의 객체화 로직(instantiation logic), 종속성 해결 로직(dependency-resolution logic) 등을 제공할 수 있다.
org.springframework.beans.factory.config.BeanPostProcessor interface는 두개의 callback 메소드로 구성되어 있다. 특정 class가 Container에 post-processor로 등록되면, post-processor는 Container에서 생성되는 각각의 bean 객체에 대해서, Container 객체화 메소드 전에 callback을 받는다.
중요한 것은 BeanFactory는 post-processor를 다루는 방식에 있어서 ApplicationContext와는 조금 다르다. ApplicationContext는 BeanPostProcessor interface를 구현한 bean을 자동적으로 인식하고 post-processor로 등록한다. 하지만 BeanFactory 구현을 사용하면 post-processor는 다음과 같이 명시적으로 등록되어야 한다.

ConfigurableBeanFactory factory = new XmlBeanFactory(...);
 
// now register any needed BeanPostProcessor instances
MyBeanPostProcessor postProcessor = new MyBeanPostProcessor();
factory.addBeanPostProcessor(postProcessor);
 
// now start using the factory

명시적인 등록은 불편하기 때문에 대부분의 Spring 기반 어플리케이션에서는 순수 BeanFactory 구현보다는 ApplicationContext 구현을 사용한다.

Example: Hello World, BeanPostProcessor-style

본 예제는 올바른 예는 아니지만, 기본적인 사용 방법을 보여주기 위함이다.

package scripting;

import org.springframework.beans.factory.config.BeanPostProcessor;
import org.springframework.beans.BeansException;

public class InstantiationTracingBeanPostProcessor implements BeanPostProcessor {
   // simply return the instantiated bean as-is
   public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
       return bean; // we could potentially return any object reference here...
   }

   public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
       System.out.println("Bean '" + beanName + "' created : " + bean.toString());
       return bean;
   }
}

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:lang="http://www.springframework.org/schema/lang"
   xsi:schemaLocation=" http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans.xsd
       http://www.springframework.org/schema/lang
       http://www.springframework.org/schema/lang/spring-lang.xsd">
 
   <lang:groovy id="messenger" script-source="classpath:org/springframework/scripting/groovy/Messenger.groovy">
       <lang:property name="message" value="Fiona Apple Is Just So Dreamy."/> 
   </lang:groovy>
 
   <!-- 
   when the above bean ('messenger') is instantiated, this custom
   BeanPostProcessor implementation will output the fact to the system console
   -->
   <bean class="scripting.InstantiationTracingBeanPostProcessor"/>
</beans>

InstantiationTracingBeanPostProcessor는 단순히 정의된다. 비록 이름을 가지고 있지는 않지만 bean이기 때문에 다른 bean과 같이 종속성은 삽입될 수 있다.

BeanFactoryPostProcesors를 사용한 확장(Customizing configuration metadata with BeanFactoryPostProcessors)

org.springframework.beans.factory.config.BeanFactoryPostProcessor는 BeanPostProcessor와 의미적으로 비슷하지만, 큰 차이점 중 하나는 BeanFactoryPostProcessors는 bean 설정 메타정보를 처리한다는 것이다. Spring IoC Container는 BeanFactoryPostProcessors가 설정 메타정보를 읽고, Container가 실제로 bean을 객체화 하기 전에 그 정보를 변경할 수 있도록 허용한다.

Bean factory post-processor는 BeanFactory의 경우 수동으로 실행되고, ApplicationContext의 경우 자동으로 실행된다.

BeanFactory에서는 다음과 같이 수동으로 실행한다.

XmlBeanFactory factory = new XmlBeanFactory(new FileSystemResource("beans.xml"));
 
// bring in some property values from a Properties file
PropertyPlaceholderConfigurer cfg = new PropertyPlaceholderConfigurer();
cfg.setLocation(new FileSystemResource("jdbc.properties"));
 
// now actually do the replacement
cfg.postProcessBeanFactory(factory);

Example: the PropertyPlaceholderConfigurer

PropertyPlaceholderConfigurer는 BeanFactory 정의로부터 property 값을 분리하기 위해 사용한다. 분리된 값은 Java Properties 형식으로 작성된 다른 파일로 분리된다. 이 방식은 주 XML 설정 파일을 변경하지 않고, 환경 변수 등을 변경할 때 유용하다.(예를 들어 database URLs, 사용자명, 패스워드 등)

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
   <property name="locations">
       <value>classpath:com/foo/jdbc.properties</value>
   </property>
</bean>
 
<bean id="dataSource" destroy-method="close" class="org.apache.commons.dbcp.BasicDataSource">
   <property name="driverClassName" value="${jdbc.driverClassName}"/>
   <property name="url" value="${jdbc.url}"/>
   <property name="username" value="${jdbc.username}"/>
   <property name="password" value="${jdbc.password}"/>
</bean>

위 설정의 실제 값은 아래와 같다.

jdbc.driverClassName=org.hsqldb.jdbcDriver
jdbc.url=jdbc:hsqldb:hsql://production:9002
jdbc.username=sa
jdbc.password=root

만약 Spring 2.5부터 지원되는 context namespace를 사용하면 다음과 같이 설정할 수 있다.

<context:property-placeholder location="classpath:com/foo/jdbc.properties"/>

PropertyPlaceholderConfigurer는 사용자가 지정한 Properties 파일 뿐 아니라 만약 지정한 property가 없을 경우, Java System properties도 검사할 수 있다. 이 기능은 systemPropertiesMode 설정을 통해 조절할 수 있다.

Example: the PropertyOverrideConfigurer

PropertyOverrideConfigurer는 또다른 bean factory post-processor로 PropertyPlaceholderConfigurer와 비슷하다. 하지만 PropertyPlaceholderConfigurer와는 반대로 원본 설정은 bean properties로 기본(default) 값을 가지거나 전혀 값을 가지지 않을 수 있다. 만약 Properties 파일이 특정 bean property를 위한 값을 가지고 있지 않을 경우, 기본 context definition이 사용된다. Properties 파일 설정의 각 줄은 다음과 같은 형식이다.

beanName.property=value

Spring 2.5부터 지원되는 context namespace를 사용하면 다음과 같이 설정할 수 있다.

<context:property-override location="classpath:override.properties"/>

FactoryBeans를 사용한 확장(Customizing instantiation logic using FactoryBeans)

org.springframework.beans.factory.FactoryBean interface를 구현한 객체는 스스로 fatory가 된다. FactoryBean interface는 Spring IoC Container에 객체화 로직을 삽입할 수 있는 방법이다. 만약 복잡한 객체화 코드를 가지고 있어 장황한 XML 설정보다는 Java로 직접 표현하는 것이 더 좋은 경우, 객체화 코드를 가지고 있는 FactoryBean를 생성하여 Container에서 삽입할 수 있다.

FactoryBean interface는 다음 3가지 메소드를 제공한다.

• Object getObject(): 생성한 객체를 return한다. 생성된 객체는 공유될 수도 있다.

• boolean isSingleton(): 만약 FactoryBean이 singleton을 리턴하면 true, 아니면 false 이다.

• Class getObjectType(): getObject() 메소드에 의해 객체의 타입을 리턴하는데 미리 알 수 없는 경우에는 null을 리턴한다.

Container에게 FactoryBean이 생성한 객체가 아닌 FactoryBean 그 자체를 요구하는 경우도 있다. 이런 경우, BeanFactory의 getBean 메소드를 호출할 때 bean id 앞에 ‘&‘를 붙이면 된다.

참고자료

• Spring Framework - Reference Document / 1.8 Container Extension Points

2.9 - The ApplicationContext

The ApplicationContext

개요

org.springframework.context 패키지는 BeanFactory 인터페이스를 확장하는 ApplicationContext 인터페이스를 추가하고, 다른 인터페이스를 확장하여 보다 애플리케이션 프레임워크 지향적인 스타일로 추가 기능을 제공한다.
많은 사람들이 ApplicationContext를 완전히 선언적인 방식으로 사용하며, 프로그래밍 방식으로 생성하지 않고 ContextLoader와 같은 지원 클래스에 의존하여 Java EE 웹 애플리케이션의 정상적인 시작 프로세스의 일부로 ApplicationContext를 자동으로 인스턴스화한다.

설명

ApplicationContext는 BeanFactory를 확장한 것으로 BeanFactory의 기능 외에 아래와 같은 기능을 제공한다.

• MessageSource : i18n-sytle로 메시지를 access할 수 있도록 지원한다.
• Access to resources : URL, File 등과 같은 자원을 쉽게 access할 수 있도록 지원하다.
• Event propagation : ApplicationListener interface를 구현한 bean에게 Event를 전달한다.
• Loading of multiple (hierarchical) contexts : 계층 구조의 context를 지원함으로써, 어플리케이션의 웹 레이어 등과 같은 특정 레이어에만 집중적인 context를 작성할 수 있다.

BeanFactory or ApplicationContext?

아주 특별한 이유가 없는 한 ApplicationContext를 사용하는 것이 좋다. 다음은 BeanFactory와 ApplicationContext의 기능 비교표이다.

MessageSources를 사용한 국제화(Internationalization using MessageSources)

본 장의 내용은 Resource를 참조한다.

Event

ApplicationContext는 Event 처리를 위해 ApplicationEvent, ApplicationListener interface를 제공한다. ApplicationListener interface를 구현한 bean은 ApplicationContext에 발생한 모든 ApplicationEvent를 전달받는다. Spring이 제공하는 표준 event는 다음과 같다.

새로운 event를 구현하는 것도 어렵지 않다. ApplicationContext interface를 구현한 새로운 event 객체를 ApplicationContext의 publishEvent() 메소드를 통해 발행하면 된다. publishEvent() 메소드는 모든 listener가 event 처리를 마칠때까지 block 상태로 있게 된다. 게다가 transaction context가 가능하다면, listener가 event를 받았을 때, 발행모듈의 transaction context 내에서 event를 처리한다.

아래는 예제이다.

<bean id="emailer" class="example.EmailBean">
   <property name="blackList">
       <list>
           <value>black@list.org</value>
           <value>white@list.org</value>
           <value>john@doe.org</value>
           </list>
   </property>
</bean>
 
<bean id="blackListListener" class="example.BlackListNotifier">
   <property name="notificationAddress" value="spam@list.org"/>
</bean>

public class EmailBean implements ApplicationContextAware {
   private List blackList;
   private ApplicationContext ctx;

   public void setBlackList(List blackList) {
       this.blackList = blackList;
   }

   public void setApplicationContext(ApplicationContext ctx) {
       this.ctx = ctx;
   }

   public void sendEmail(String address, String text) {
       if (blackList.contains(address)) {
           BlackListEvent event = new BlackListEvent(address, text);
           ctx.publishEvent(event);
           return;
       }
       // send email...
   }
}

public class BlackListNotifier implements ApplicationListener {
   private String notificationAddress;

   public void setNotificationAddress(String notificationAddress) {
       this.notificationAddress = notificationAddress;
   }

   public void onApplicationEvent(ApplicationEvent event) {
       if (event instanceof BlackListEvent) {
           // notify appropriate person...
       }
   }
}

웹 어플리케이션을 위한 편리한 ApplicationContext 객체화(Convenient ApplicationContext instantiation for web applications)

BeanFactory가 프로그램적으로 생성되는 것과 반대로, ApplicationContext 객체는 ContextLoader 등을 사용하여 선언적으로 생성될 수 있다. 물론 ApplicationContext 객체 역시 프로그램적으로 생성할 수 있다.
ContextLoader에는 ContextLoaderListener와 ContextLoaderServlet가 있다. 둘 다 기능적으로는 같지만, listener 버전은 Servlet 2.3 컨테이너에서는 사용할 수 있다.
Servlet 2.4 스팩 이후로, servlet context listener는 웹 어플리케이션을 위한 servlet context가 생성되어 첫번째 요청을 처리할 상태가 된 직후 수행된다(그리고 servlet context가 막 종료되었을 때도 수행된다).
따라서 servlet context listner가 Spring ApplicationContext를 초기화할 최적의 장소이다.
ContextLoaderListener를 사용하여 ApplicationContext를 등록하는 방법은 아래와 같다.

<context-param>
   <param-name>contextConfigLocation</param-name>
   <param-value>/WEB-INF/daoContext.xml /WEB-INF/applicationContext.xml</param-value>
</context-param>
 
<listener>
   <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
 
<!-- or use the ContextLoaderServlet instead of the above listener
<servlet>
   <servlet-name>context</servlet-name>
   <servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class>
   <load-on-startup>1</load-on-startup>
</servlet>
-->

Listener는 ‘contextConfigLocation’ 파라미터를 검사한다. 만약 존재하지 않으면 기본적으로 /WEB-INF/applicationContext.xml를 사용할 것이다.
만약 ‘contextConfigLocation’ 파라미터 값이 존재할 경우, 미리 정해놓은 구분자(comma(’,’), semicolon(’;’), 공백문자(whitespace))를 사용하여 파라미터 문자열을 분리한 후, application context를 찾을 것이다.
Ant-style path 패턴이 지원된다. 예를 들어 /WEB-INF/*Context.xml’은 “WEB-INF” 디렉토리에 존재하는 “Context.xml”로 끝나는 이름을 가진 모든 파일을 의미하고, \
/WEB-INF/**/*Context.xml은 “WEB-INF” 디렉토리 및 하위 디렉토리에 존재하는 “Context.xml”로 끝나는 이름을 가진 모든 파일을 의미한다.

참고자료

• Spring Framework - Reference Document / 1.15 Additional capabilities of the ApplicationContext

2.10 - Annotation-based Configuration

Annotation-based configuration

개요

Spring Framework는 Spring의 종속성 삽입을 위해 annotation을 사용할 수 있다. Spring 2.0에서는 @Required 어노테이션으로 필수 속성을 강제할 수 있는 기능이 도입되었고 Spring 2.5에서는 이와 동일한 일반적인 접근 방식을 따라 Spring의 의존성 주입을 구동할 수 있게 되었으며, Spring 3.0부터 @Inject 및 @Named와 같이 javax.inject 패키지에 포함된 JSR-330(Java용 의존성 주입) 어노테이션에 대한 지원이 추가되었다.

설명

Spring @Autowired annotation은 자동 엮음과 같은 기능을 제공하지만, 좀 더 세밀한 제어와 넓은 사용성을 제공한다. Spring Framework는 @Resource, @PostConstruct, @PreDestroy 등의 JSR-250 annotation도 지원한다. 이들 annotation을 사용하기 위해서는 Spring Container에 특정 BeanPostProcessors를 등록해야만 한다. 항상 그렇듯이, 이들 BeanPostProcessors가 개별적인 bean 정의로 등록될 수도 있지만, ‘context’ namespace를 사용하여 등록할 수도 있다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:context="http://www.springframework.org/schema/context"
   xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans.xsd
       http://www.springframework.org/schema/context
       http://www.springframework.org/schema/context/spring-context.xsd">
 
   <context:annotation-config/>
</beans>

(위 <context:annotation-config/> tag를 사용하면, AutowiredAnnotationBeanPostProcessor, CommonAnnotationBeanPostProcessor, PersistenceAnnotationBeanPostProcessor, RequiredAnnotationBeanPostProcessor를 등록해 준다.)

@Required

@Required annotation은 bean property setter 메소드에 적용된다.

public class SimpleMovieLister {
   private MovieFinder movieFinder;
 
   @Required
   public void setMovieFinder(MovieFinder movieFinder) {
       this.movieFinder = movieFinder;
   }
 
   // ...
}

이 annotation은 단순히 bean property가 설정 시 반드시 설정되어야만 한다는 것을 나타낸다. 즉, bean 정의에 명시적으로 property 값을 선언하거나 자동 엮임을 통해서 설정되어야만 한다는 것을 의미한다. 만약 annotation이 적용된 bean property에 대한 설정이 이루어지지 않는 경우, Container는 exception을 던진다.

@Autowired

@Autowired annotation은 “전통적인” setter 메소드에 적용된다.

public class SimpleMovieLister {
   private MovieFinder movieFinder;
 
   @Autowired
   public void setMovieFinder(MovieFinder movieFinder) {
       this.movieFinder = movieFinder;
   }

   // ...
}

뿐만 아니라, 임의의 이름과 다수의 argument를 가진 메소드에도 적용될 수 있다.

public class MovieRecommender {
   private MovieCatalog movieCatalog;
 
   private CustomerPreferenceDao customerPreferenceDao;
 
   @Autowired
   public void prepare(MovieCatalog movieCatalog, CustomerPreferenceDao customerPreferenceDao) {
       this.movieCatalog = movieCatalog;
       this.customerPreferenceDao = customerPreferenceDao;
   }
 
   // ...
}

또한, @Autowired annotation은 생성자 및 field에도 적용될 수 있다.

public class MovieRecommender {
   @Autowired
   private MovieCatalog movieCatalog;
 
   private CustomerPreferenceDao customerPreferenceDao;
 
   @Autowired
   public MovieRecommender(CustomerPreferenceDao customerPreferenceDao) {
       this.customerPreferenceDao = customerPreferenceDao;
   }
 
   // ...
}

또한, array 타입의 field나 메소드에 적용함으로써, ApplicationContext에 존재하는 특정 Type의 모든 bean을 field나 메소드에 제공하는 것도 가능한다.

public class MovieRecommender {
 
   @Autowired
   private MovieCatalog[] movieCatalogs;
 
   // ...
}

Typed collections에도 같은 방식이 적용된다.

public class MovieRecommender {
   private Set<MovieCatalog> movieCatalogs;
 
   @Autowired
   public void setMovieCatalogs(Set<MovieCatalog> movieCatalogs) {
       this.movieCatalogs = movieCatalogs;
   }
 
   // ...
}

심지어 typed Map 역시 key 타입이 String인 한 자동 엮임이 가능하다. Map은 기대한 타입의 모든 bean을 value로 갖게 되고, key는 해당하는 bean의 이름이 된다.

public class MovieRecommender {
   private Map<String, MovieCatalog> movieCatalogs;

   @Autowired
   public void setMovieCatalogs(Map<String, MovieCatalog> movieCatalogs) {
       this.movieCatalogs = movieCatalogs;
   }

   // ...
}

기본적으로, 자동 엮임은 대상이 되는 bean이 없을 경우 실패한다. 기본적으로 annotation이 적용된 메소드, 생성자, field는 필수로 간주한다. 아래와 같이 설정하여 기본 행동 방식을 변경할 수 있다.

public class SimpleMovieLister {
   private MovieFinder movieFinder;
 
   @Autowired(required=false)
   public void setMovieFinder(MovieFinder movieFinder) {
       this.movieFinder = movieFinder;
   }
 
   // ...
}

@Autowired annotation은 잘 알려진 “분석가능한 종속성(resolvable dependencies)“에도 사용될 수 있다 : BeanFactory interface, ApplicationContext interface, ResourceLoader interface, ApplicationEventPublisher interface, MessageSource interface(그리고 이들을 상속한 ConfigurableApplicationContext 또는 ResourcePatternResolver interface)는 특별한 설정 없이 자동적으로 해결(resolve)된다.

Qualifier를 사용한 annotation 기반의 자동 엮음(Fine-tuning annotation-based autowiring with qualifiers)

Type을 이용한 자동 엮기는 대상이 다수가 발생할 수 있기 때문에, 선택 시 추가적인 제어가 필요하다. 한 방법으로 Spring의 @Qualifier annotation을 사용할 수 있다. 특정 argument를 qualifier와 관련시킴으로써, 타입을 찾을 대상을 좁히고, 각 argument에 해당하는 대상 bean을 선택할 수 있다.

public class MovieRecommender {
 
   @Autowired
   @Qualifier("main")
   private MovieCatalog movieCatalog;
 
   // ...
}

@Qualifier annotation은 생성자의 argument 및 메소드의 parameter 각각에 적용할 수 있다.

public class MovieRecommender {
 
   private MovieCatalog movieCatalog;
 
   private CustomerPreferenceDao customerPreferenceDao;
 
   @Autowired
   public void prepare(@Qualifier("main") MovieCatalog movieCatalog, CustomerPreferenceDao customerPreferenceDao) {
       this.movieCatalog = movieCatalog;
       this.customerPreferenceDao = customerPreferenceDao;
   }
 
   // ...
}

일치하는 bean 정의는 아래 예제에서 찾을 수 있다. Qualifier “main” 값을 가진 bean이 같은 값의 @Qualifier annotation이 있는 생성자 argument로 엮인다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:context="http://www.springframework.org/schema/context"
   xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans.xsd
       http://www.springframework.org/schema/context
       http://www.springframework.org/schema/context/spring-context.xsd">
 
   <context:annotation-config/>
 
   <bean class="example.SimpleMovieCatalog">
       <qualifier value="main"/>
       <!-- inject any dependencies required by this bean -->
   </bean>
 
   <bean class="example.SimpleMovieCatalog">
       <qualifier value="action"/>
       <!-- inject any dependencies required by this bean -->
   </bean>
 
   <bean id="movieRecommender" class="example.MovieRecommender"/>
 
</beans>

대체 수단으로, bean 이름을 qualifier로 간주된다. 즉, qualifier element 대신 bean id가 “main”이라면 동일하게 동작한다. 어쨌든, 이름으로 bean을 찾는게 더 좋지만, @Autowired는 기본적으로 type을 기반으로 동작하고 qualifier는 선택적이다. 즉, 타입으로 bean 대상을 줄인 후에 qualifier 또는 bean name으로 대상을 좁힌다. Qualifier 값은 의미적으로 유일한 bean id를 나타내지는 않는다. 좋은 qualifier 값은 “main”, “EMEA”, “persistent” 등과 같이 bean id가 아닌 특정 컴포넌트의 특징을 표현하는 것이다. Qualifier는 typed collection에도 적용된다.

@Resource

Spring은 field나 bean property setter 메소드에 적용된 JSR-250 @Resource annotation을 사용하여 종속성 삽입을 지원한다. @Resource는 ’name’ attribute를 가지고, Spring은 그 값을 삽입할 bean 이름으로 인식한다.

public class SimpleMovieLister {
   private MovieFinder movieFinder;
 
   @Resource(name="myMovieFinder")
   public void setMovieFinder(MovieFinder movieFinder) {
       this.movieFinder = movieFinder;
   }
}

만약 name이 명식적으로 설정되어 있지 않으면, field나 setter 메소드의 이름으로부터 name 값을 유추해낸다. Field의 경우, field 명과 같다. Setter 메소드의 경우, bean property 이름과 같다. 아래 예제에서는 “movieFinder” bean이 삽입된다.

public class SimpleMovieLister {
   private MovieFinder movieFinder;
 
   @Resource
   public void setMovieFinder(MovieFinder movieFinder) {
       this.movieFinder = movieFinder;
   }
}

@Autowired와 비슷하게, @Resource도 대안으로 bean type으로 대상을 찾는다. 뿐만 아니라 잘 알려진 “resolvable dependencies”로 해결한다. 둘 다 명시적으로 name을 설정하지 않은 경우 적용된다. 다음 예에서 customerPreferenceDao field를 위해서 “customerPreferenceDao” 이름을 가진 bean을 먼저 찾는다. 그 다음으로 CustomerPreferenceDao Type의 bean을 찾는다. “context” field는 알려진 해결가능한 종속성 type인 ApplicationContext에 기반하여 삽입된다.

public class MovieRecommender {
   @Resource
   private CustomerPreferenceDao customerPreferenceDao;
 
   @Resource
   private ApplicationContext context;
 
   public MovieRecommender() {
   }
 
   // ...
}

@PostConstrutor와 @PreDestroy

CommonAnnotationBeanPostProcessor는 @Resource annotation 뿐 아니라 JSR-250 lifecycle annotation 역시 인식한다.

public class CachingMovieLister {
   @PostConstruct
   public void populateMovieCache() {
       // populates the movie cache upon initialization...
   }
 
   @PreDestroy
   public void clearMovieCache() {
       // clears the movie cache upon destruction...
   }
}

참고자료

• Spring Framework - Reference Document / 1.9. Annotation-based Container Configuration

2.11 - Classpath Scanning for Managed Components

Classpath scanning for managed components

개요

본 장의 앞선 대부분의 예제들은 Spring Container 안에서 BeanDefinition을 생성하기 위한 설정 메타데이터를 명기하기 위해서 XML을 사용해왔다. 이전 section Annotaion-based configuration은 source-level annotation을 사용하여 많은 양의 설정 메타데이터를 제공할 수 있음을 보였다. 이들 예제에서도 어쨌든, “base” bean 정의가 XML 파일 안에 명시적으로 정의되었다. 이번 section은 classpath를 검색하고, filter를 통해 검사함으로써, 대상 컴퍼넌트(candidate component) 를 검출하는 방법을 소개한다.

설명

@Component and further stereotype annotations

Spring 2.0부터 Data Access Object(DAO) 등과 같은 repository를 표시하기 위해서 @Repository annotation이 소개되었다. Spring 2.5는 추가적으로 @Component, @Service, @Controller annotation을 제공한다. @Component는 Spring이 관리하는 컴포넌트를 위한 포괄적인 stereotype을 나타낸다. 그리고 @Repository, @Service, @Controller는 좀 더 특별한 사용을 위한 @Component의 일종이다. (각각 persistence, service, presentation layer의 component를 의미한다.)

Auto-detection Components

Spring은 ‘stereotyped’ class를 자동으로 탐지하고 ApplicationContext에 일치하는 BeanDefinition을 등록하는 기능을 제공한다. 아래 두 class는 자동 탐지의 대상이 된다.

@Service
public class SimpleMovieLister {
   private MovieFinder movieFinder;
 
   @Autowired
   public SimpleMovieLister(MovieFinder movieFinder) {
       this.movieFinder = movieFinder;
   }
}

@Repository
public class JpaMovieFinder implements MovieFinder {
   // implementation elided for clarity
}

실제로 위 두 class를 자동 탐지하고 상응하는 bean을 등록하기 위해서는, 아래 예제 XML의 <context:component-scan/> element의 ‘basePackage’가 위 두 class의 공통 부모 package이어야 한다(또는 comma(’,’)로 구분된 list 역시 가능하다).

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:context="http://www.springframework.org/schema/context"
   xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans.xsd
       http://www.springframework.org/schema/context
       http://www.springframework.org/schema/context/spring-context.xsd">
 
   <context:component-scan base-package="org.example"/>
 
</beans>

Naming autodetected components

검색 과정에서 component가 자동 탐지되었을 때, bean 이름은 scan하고 있는 BeanNameGenerator 전략에 따라 생성된다. 기본적으로 name 값을 가지고 있는 Spring ‘stereotype’ annotation(@Component, @Repository, Service, Controller)는 상응하는 bean 정의에게 이름을 제공한다. 만약 이들 annotation이 name이 없거나 또 다른 탐지된 component인 경우, 기본 bean name generator는 class 이름의 첫 문자를 소문자로 변환한 값을 return할 것이다. 예를 들어, 아래 예제에서 두개의 component가 탐지되는데 각각의 이름은 ‘myMovieLister’와 ‘movieFinderImpl’이다.

@Service("myMovieLister")
public class SimpleMovieLister {
   // ...
}

@Repository
public class MovieFinderImpl implements MovieFinder {
   // ...
}

Providing a scope for autodetected components

일반적으로 Spring 관리 component는 ‘singleton’이다. 어쨌든 다른 scope이 필요한 경우가 있다. Spring Framework는 @Scope annotation을 제공한다.

@Scope("prototype")
@Repository
public class MovieFinderImpl implements MovieFinder {
   // ...
}

Providing qualifier metadata with annotations

이번 section에서는 자동 엮임의 대상을 찾을 때 상세한 제어를 제공하기 위해 @Qualifier annotation을 사용하는 방법을 설명한다.

@Component
@Qualifier("Action")
public class ActionMovieCatalog implements MovieCatalog {
   // ...
}

참고자료

• Spring Framework - Reference Document / 1.10 Classpath scanning and managed components

2.12 - JSR 330 표준 어노테이션 사용하기

JSR 330 표준 어노테이션 사용하기

개요

스프링 3.0부터 JSR-330 표준 어노테이션(의존성 주입)을 지원한다. 이 어노테이션들은 스프링 어노테이션들과 같은 방법으로 스캔된다. 이 어노테이션들을 사용하기 위해서는 클래스패스에 관련 jar 파일들을 가지고 있어야 한다.
Maven을 사용한다면 Maven Repository(https://mvnrepository.com/artifact/javax.inject/javax.inject/1)에서 javax.inject라는 아티펙트가 제공된다. pom.xml 파일에 아래의 의존성을 추가하여 사용할 수 있다.

<dependency>
   <groupId>javax.inject</groupId>
   <artifactId>javax.inject</artifactId>
   <version>1</version>
</dependency>

설명

1. @Inject 와 @Named 를 이용한 의존성 주입

@Autowired를 대신하여 @javax.inject.Inject를 아래와 같이 사용할 수 있다.

import javax.inject.Inject;
 
public class SimpleMovieLister {
   private MovieFinder movieFinder;
 
   @Inject
   public void setMovieFinder(MovieFinder movieFinder) {
       this.movieFinder = movieFinder;
   }
 
   public void listMovies() {
       this.movieFinder.findMovies(...);
       // ...
   }
}

@Autowired와 같이 @Inject를 필드 수준, 함수 수준, 생성자 인자 수준으로 사용할 수 있고, 주입 지점을 Provider로 선언할 수 있으며 Provider.get() 호출을 통해 근접 범위의 Bean들에 대한 요청 시 접근 또는 다른 Bean에 대한 지연된 접근을 허용할 수 있다.

import javax.inject.Inject;
import javax.inject.Provider;
 
public class SimpleMovieLister {
   private Provider<MovieFinder> movieFinder;
 
   @Inject
   public void setMovieFinder(Provider<MovieFinder> movieFinder) {
       this.movieFinder = movieFinder;
   }
 
   public void listMovies() {
       this.movieFinder.get().findMovies(...);
       // ...
   }
}

주입될 의존성에 대해 지정된 이름을 사용하고자 할 경우에는 아래와 같이 @Named 어노테이션을 사용할 수 있다.

import javax.inject.Inject;
import javax.inject.Named;
 
public class SimpleMovieLister {
   private MovieFinder movieFinder;
 
   @Inject
   public void setMovieFinder(@Named("main") MovieFinder movieFinder) {
       this.movieFinder = movieFinder;
   }
 
   // ...
}

2. @Component 어노테이션과 동일한 표준인 @Named, @ManagedBean 어노테이션

@Component를 대신하여, @javax.inject.Named나 javax.annotation.ManagedBean를 아래와 같이 사용할 수 있다.

import javax.inject.Inject;
import javax.inject.Named;
 
@Named("movieListener")  // @ManagedBean("movieListener") could be used as well
public class SimpleMovieLister {
   private MovieFinder movieFinder;
 
   @Inject
   public void setMovieFinder(MovieFinder movieFinder) {
       this.movieFinder = movieFinder;
   }
 
   // ...
}

일반적으로 컴포넌트에 대한 이름을 명시하지 않고 @Component를 사용할 수 있는데, 아래 예제처럼 @Named도 비슷하게 사용할 수 있다.

import javax.inject.Inject;
import javax.inject.Named;
 
@Named
public class SimpleMovieLister {
   private MovieFinder movieFinder;
 
   @Inject
   public void setMovieFinder(MovieFinder movieFinder) {
       this.movieFinder = movieFinder;
   }
 
   // ...
}

@Named나 @ManagedBean을 사용할 때 아래 예제에서 보여주는 것처럼 스프링 어노테이션과 같이 동일한 방법으로 컴포넌트 탐색이 가능하다.

@Configuration
@ComponentScan(basePackages = "org.example")
public class AppConfig  {
   // ...
}

3. JSR-330 표준 어노테이션의 제한점

표준 어노테이션으로 작업할 때 아래 표와 같이 일부 중요한 기능이 사용 불가능하다.

참고자료

• Spring Framework - Reference Document / 1.11. Using JSR 330 Standard Annotations

2.13 - Java-based Configuration

Java-based configuration

개요

Java 코드에서 주석을 사용하여 스프링 컨테이너를 구성하는 방법에 대해 알아본다.

설명

기본 개념 : @Bean, @Configurationl

스프링의 자바 기반 설정에서는 @Configuration 어노테이션 클래스와 @Bean 어노테이션 메소드를 지원한다.
@Bean 어노테이션은 Spring IoC 컨테이너가 관리할 새로운 객체를 인스턴스화하고, 초기화하는데 사용되며, Spring의 XML 설정에서의 <bean/>과 같은 역할을 한다.
@Bean 어노테이션은 붙인 메소드는 스프링 @Component와 함께 사용할 수 있지만, 대체로 @Configuration Bean과 사용한다.
@Configuration 어노테이션은 해당 클래스의 목적이 Bean 설정을 위한 소스임을 나타내며, @Configuration 클래스는 같은 클래스 안에 있는 @Bean 메소드들끼리 서로를 호출하여 Bean 사이의 의존성을 정의할 수 있게 한다.
@Configuration 클래스를 아래와 같이 구성할 수 있다.

@Configuration
public class AppConfig {
   @Bean
   public MyService myService() {
       return new MyServiceImpl();
   }
}

예제의 AppConfig 클래스는 아래의 Spring <bean/> XML과 동일한 역할을 한다.

<beans>
   <bean id="myService" class="com.acme.services.MyServiceImpl"/>
</beans>

AnnotationConfigApplicationContext를 이용한 스프링 컨테이너 인스턴스화

AnnotationConfigApplicationContext는 다재다능한 ApplicationContext 구현체로, 입력으로 @Configuration 클래스뿐만 아니라 평범한 @Component 클래스와 JSR-330 메타데이터로 어노테이션이 붙은 클래스들도 받아들일 수 있다.
@Configuration 클래스가 입력으로 제공되면 @Configuration 클래스 자체가 Bean 정의로 등록되고, 해당 클래스내의 선언된 모든 @Bean 메서드들도 Bean 정의로 등록된다.
@Component와 JSR-330 클래스들이 제공되면 이 클래스들은 Bean 정의로 등록되고 해당 클래스내에서 필요한 곳에 @Autowired나 @Inject 같은 DI 메타데이터가 사용되었다고 가정한다.

간단한 구성

ClassPathXmlApplicationContext를 인스턴스화 할 때 스프링 XML 파일을 사용하는 방법과 거의 동일하게 AnnotationConfigApplicationContext를 인스턴스화 할 때 @Configuration 클래스들을 입력으로 사용할 것이다.
이를 통해 전혀 XML을 사용하지 않고 스프링 컨테이너를 사용할 수 있다.

public static void main(String[] args) {
   ApplicationContext ctx = new AnnotationConfigApplicationContext(AppConfig.class);
   MyService myService = ctx.getBean(MyService.class);
   myService.doStuff();
}

register(Class…)로 프로그래밍 방식으로 컨테이너 빌드

인수 없는 생성자를 사용하여 AnnotationConfigApplicationContext를 인스턴스화한 다음 register() 메서드를 사용하여 구성할 수 있다.
이 접근 방식은 AnnotationConfigApplicationContext를 프로그래밍 방식으로 빌드할 때 특히 유용하며 아래와 같이 사용할 수 있다.

public static void main(String[] args) {
   AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
   ctx.register(AppConfig.class, OtherConfig.class);
   ctx.register(AdditionalConfig.class);
   ctx.refresh();
   MyService myService = ctx.getBean(MyService.class);
   myService.doStuff();
}

scan(String…)으로 컴포넌트 스캔

@Configuration구성 요소 스캔을 활성화하려면 다음과 같이 구성할 수 있다.

@Configuration
@ComponentScan(basePackages = "com.acme") // 구성요소 스캔을 활성화함
public class AppConfig  {
   // ...
}

경험있는 스프링 사용자들은 다음과 같이 일반적으로 사용되는 스프링의 context: 네임스페이스로 XML을 선언하는데 익숙할 것이다.

<beans>
   <context:component-scan base-package="com.acme"/>
</beans>

위의 예제에서 com.acme 팩키지는 스캔되고 @Component 어노테이션이 붙은 클래스들을 찾고 이러한 클래스를 컨테이너내 스프링 빈 정의로 등록할 것이다.
AnnotationConfigApplicationContext에는 같은 컴포넌트 스캔 기능을 하는 scan(String…) 메서드가 있다.

public static void main(String[] args) {
   AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
   ctx.scan("com.acme");
   ctx.refresh();
   MyService myService = ctx.getBean(MyService.class);
}

AnnotationConfigWebApplicationContext를 사용한 웹 어플리케이션 지원

AnnotationConfigApplicationContext의 WebApplicationContext 변형은 AnnotationConfigWebApplicationContext로 사용할 수 있다.
이 구현체는 스프링 ContextLoaderListener 서블릿 리스너, 스프링 MVC DispatcherServlet 등을 설정할 때 사용할 수 있다.
아래는 전형적인 스프링 MVC 웹 어플리케이션을 설정하는 web.xml의 예제로 contextClass context-param과 init-param의 사용방법을 보여준다.

<web-app>
   <!-- 기본 XmlWebApplicationContext 대신 AnnotationConfigWebApplicationContext를 사용하는 ContextLoaderListener를 설정한다. -->
   <context-param>
       <param-name>contextClass</param-name>
       <param-value>
           org.springframework.web.context.support.AnnotationConfigWebApplicationContext
       </param-value>
   </context-param>
 
   <!-- 설정 위치는 반드시 콤마나 공백을 구분자로 사용하는 하나 이상의 정규화된 @Configuration 클래스들로 구성되어야 한다. 정규화된 패키지는 컴포넌트 스캔으로 지정될 수도 있다. -->
   <context-param>
       <param-name>contextConfigLocation</param-name>
       <param-value>com.acme.AppConfig</param-value>
   </context-param>
 
   <!-- ContextLoaderListener를 사용해서 루트 어플리케이션 시작한다. -->
   <listener>
       <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
   </listener>
 
   <!-- Spring MVC DispatcherServlet 시작 -->
   <servlet>
       <servlet-name>dispatcher</servlet-name>
       <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
       <!-- 기본 XmlWebApplicationContext 대신 AnnotationConfigWebApplicationContext를 사용한 DispatcherServlet 설정한다. -->
       <init-param>
           <param-name>contextClass</param-name>
           <param-value>
               org.springframework.web.context.support.AnnotationConfigWebApplicationContext
           </param-value>
       </init-param>
       <!-- 다시한번, 설정 위치는 반드시 콤마나 공백을 구분자로 사용하는 하나 이상의 정규화된 @Configuration 클래스들로 구성되어야 한다. -->
       <init-param>
           <param-name>contextConfigLocation</param-name>
           <param-value>com.acme.web.MvcConfig</param-value>
       </init-param>
   </servlet>
 
   <!-- /app/*에 대한 모든 요청을 디스패쳐 서블릿에 매핑한다. -->
   <servlet-mapping>
       <servlet-name>dispatcher</servlet-name>
       <url-pattern>/app/*</url-pattern>
   </servlet-mapping>
</web-app>

@Bean 어노테이션 사용

@Bean은 메소드 레벨 어노테이션이며 XML <bean/> 요소와 동일하며 <bean/>에서 제공하는 일부 속성을 지원한다. 또한, @Configuration 어노테이션 또는 @Component 어노테이션 클래스에서 @Bean 어노테이션을 사용할 수 있다.

Bean 선언

메소드에 @Bean 어노테이션을 사용하면 Bean으로 선언된다. 이 메서드를 사용하여 메서드의 반환 값으로 지정된 유형의 ApplicationContext 내에 Bean 정의를 등록되며 Bean 이름은 메서드 이름과 동일하다.
다음 예제에서 @Bean 메소드 선언을 확인할 수 있다.

@Configuration
public class AppConfig {
   @Bean
   public TransferServiceImpl transferService() {
       return new TransferServiceImpl();
   }
}

위 예제는 다음 Spring XML과 정확히 동일하다.

<beans>
   <bean id="transferService" class="com.acme.TransferServiceImpl"/>
</beans>

Bean 종속성

@Bean 어노테이션 메서드는 해당 Bean을 빌드하는 데 필요한 종속성을 설명하는 임의 개수의 매개변수를 가질 수 있다.
예를 들어 TransferService에 AccountRepository가 필요한 경우 다음 예제와 같이 메서드 매개 변수를 사용하여 해당 종속성을 구체화할 수 있다.

@Configuration
public class AppConfig {
   @Bean
   public TransferService transferService(AccountRepository accountRepository) {
       return new TransferServiceImpl(accountRepository);
   }
}

@Scope 어노테이션 사용

@Bean 어노테이션으로 정의된 Bean이 특정 범위를 갖도록 지정할 수 있으며, 선언된 Bean의 범위는 Bean scope에 지정된 표준 범위를 사용할 수 있다. 기본 범위는 싱글톤이지만 다음 예제와 같이 @Scope 어노테이션으로 이를 재정의할 수 있다.

@Configuration
public class MyConfiguration {
   @Bean
   @Scope("prototype")
   public Encryptor encryptor() {
       // ...
   }
}

@Configuration 어노테이션 사용

@Configuration은 객체가 Bean 정의의 소스임을 나타내는 클래스 수준 어노테이션이며 @Configuration 클래스는 @Bean 어노테이션 메서드를 통해 빈을 선언한다.
@Configuration 클래스의 @Bean 메소드에 대한 호출은 bean 간 종속성을 정의하는 데에도 사용할 수 있다.

@Configuration
public class AppConfig {
   @Bean
   public BeanOne beanOne() {
       return new BeanOne(beanTwo());
   }
 
   @Bean
   public BeanTwo beanTwo() {
       return new BeanTwo();
   }
}

Java 기반 설정 구성

Spring의 Java 기반 설정 기능을 사용하면 구성의 복잡성을 줄일 수 있는 어노테이션을 작성할 수 있다.

@Import 어노테이션 사용

스프링 XML 파일에서 설정 모듈화에 <import/>요소를 사용하기는 하지만 @Import 어노테이션은 다른 설정 클래스에서 @Bean 설정을 로딩한다.

@Configuration
public class ConfigA {
   @Bean
   public A a() {
       return new A();
   }
}
 
@Configuration
@Import(ConfigA.class)
public class ConfigB {
   @Bean
   public B b() {
       return new B();
   }
}

이제 컨텍스트를 인스턴스화 할 때 ConfigA.class와 ConfigB.class를 둘 다 지정해야하는 대신 ConfigB만 명시적으로 제공하면 된다.

public static void main(String[] args) {
   ApplicationContext ctx = new AnnotationConfigApplicationContext(ConfigB.class);

   // now both beans A and B will be available...
   A a = ctx.getBean(A.class);
   B b = ctx.getBean(B.class);
}